[Accepted] SE-0153: Compensate for the inconsistency of `@NSCopying`'s behaviour

Proposal Link: swift-evolution/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md at master · apple/swift-evolution · GitHub

Hello Swift Community,

The review of SE-0153 "Compensate for the inconsistency of `@NSCopying`'s behaviour” ran from February 17…22, 2017. The proposal is accepted using the “compiler magic” approach, where the compiler will introduce the copy within the initialization to maintain the invariant that the stored property is always initialized with or set to a copy of the provided value.

Feedback from the review was mixed. There was general agreement that this was a real problem that does require a solution, but the discussion during the review slightly favored the more conservative approach of adding a warning in the compiler. This was based on two main concerns about introducing the copy within the initializer:

1) @NSCopying would act differently from didSet, the latter of which still would not be called within initializers, and
2) Concern that property behaviors would not be able to model the semantics described here.

The core team felt that @NSCopying needs to guarantee that the copy occurs under all circumstances, and that a change in language semantics here is warranted. Regarding concern (1), the core team felt that @NSCopying and didSet are different enough that different behavior is reasonable and expected. Regarding concern (2), the core team noted that property behaviors can model the new semantics by providing behaviors with an extra customization point that is invoked from within the initializer (and does not have access to “self”). Moreover, having this customization point in property behaviors will make concern (1) less acute, because property behaviors can and will differ in their initialization vs. setting behavior.

  - Doug,
  Review Manager