[swift-users] @NSCopying semantic does not appear to copy in Swift initializer

Jordan Rose jordan_rose at apple.com
Fri Jan 27 12:56:37 CST 2017


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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170127/4f050b44/attachment.html>


More information about the swift-users mailing list