Your observation is correct: @NSCopying currently does not affect initializers.
This is because accessing a property in an initializer always does direct
access to the storage rather than going through the setter. It might be
reasonable to change this behavior, but it probably deserves a bit of
discussion on swift-evolution; it's not 100%, for-sure a bug. (There is a Radar
for this, rdar://problem/21383959 <rdar://problem/21383959>, but no
bugs.swift.org <http://bugs.swift.org/> issue.)
Jordan
> On Jan 26, 2017, at 23:30, Torin Kwok via swift-users <swift-users@swift.org>
> wrote:
>
> Hello guys,
>
> I wanna ask a question about the behavior of `@NSCopying` semantic in
> Swift 3. Well, according to Apple's official documentation:
>
>> In Swift, the Objective-C copy property attribute translates to
>> @NSCopying. The type of the property must conform to the NSCopying
>> protocol.
>
> However, I encountered a strange behavior when I declared a property
> with the `@NSCopying` attribute:
>
> ```
> // `Person` class inherits from `NSObject` class and conforms to `NSCopying`
> protocol
> @NSCopying var employee: Person
> ```
>
> and then assigned an external instance of `Person` class protocol to
> this property within the designated init methods:
>
> ```
> // Designated initializer of `Department` class
> init( employee externalEmployee: Person ) {
> self.employee = externalEmployee
> super.init()
>
> // Assertion would fail because Swift do not actually copy the value
> assigned to this property
> // even though `self.employee` has been marked as `@NSCoyping`
> // assert( self.employee !== externalEmployee )
> }
> ```
>
> If I indeed require the deep copying behavior during the init process,
> instead of making advantage of `@NSCopying` attribute, I have to
> invoke the `copy()` method manually:
>
> ```
> init( employee externalEmployee: Person ) {
> // ...
> self.employee = externalEmployee.copy() as! Person
> // ...
> }
> ```
>
> In fact, what really makes me confusing is that `@NSCopying` semantic
> does work properly within the other parts of the class definition such
> as normal instance methods, or external scope. For instance, if we're
> assigning an external instance of `Person` to the `self.employee` proper
> of `Department` directly through setter rather than initializer:
>
>> department.employee = johnAppleseed
>
> then `self.employee` property and `johnAppleseed` variable will no
> longer share the same underlying object now. In the other words,
> `@NSCopying` attribute makes sense.
>
> After I looked through a great deal of results given by Google, and
> dicussions on StackOverflow, I finally found nothing related — the vast
> majority of articles, documentations as well as issues talking about
> this similar topics only focus on the basic concepts and effects of
> `@NSCopying` itself but do not mentioned this strange behavior at all —
> besides one radar descriping the same problem (rdar://21383959) and a
> final conclusion mentioned in a guy's Gist comment: **... values set
> during initialization are not cloned ...**
>
> That is, `@NSCopying` semantic has no effect in initializers.
>
> Then, what I want to figure out is the reason why `@NSCopying` semantic
> will become effectless implicitly whithin initializers of a class, and
> the special considerations behind this behavior, if any.
>
> Thank you very much.
>
> Best Regards,
> Torin Kwok
>
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
