<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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,&nbsp;<a href="rdar://problem/21383959" class="">rdar://problem/21383959</a>, but no <a href="http://bugs.swift.org" class="">bugs.swift.org</a>&nbsp;issue.)</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 26, 2017, at 23:30, Torin Kwok via swift-users &lt;<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello guys,<br class=""><br class="">I wanna ask a question about the behavior of `@NSCopying` semantic in<br class="">Swift 3. Well, according to Apple's official documentation:<br class=""><br class=""><blockquote type="cite" class="">In Swift, the Objective-C copy property attribute translates to<br class="">@NSCopying. The type of the property must conform to the NSCopying<br class="">protocol.<br class=""></blockquote><br class="">However, I encountered a strange behavior when I declared a property<br class="">with the `@NSCopying` attribute:<br class=""><br class="">```<br class="">// `Person` class inherits from `NSObject` class and conforms to `NSCopying` protocol<br class="">@NSCopying var employee: Person<br class="">```<br class=""><br class="">and then assigned an external instance of `Person` class protocol to<br class="">this property within the designated init methods:<br class=""><br class="">```<br class="">// Designated initializer of `Department` class<br class="">init( employee externalEmployee: Person ) {<br class=""> &nbsp;self.employee = externalEmployee<br class=""> &nbsp;super.init()<br class=""><br class=""> &nbsp;// Assertion would fail because Swift do not actually copy the value assigned to this property &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br class=""> &nbsp;// even though `self.employee` has been marked as `@NSCoyping`<br class=""> &nbsp;// assert( self.employee !== externalEmployee )<br class=""> &nbsp;}<br class="">```<br class=""><br class="">If I indeed require the deep copying behavior during the init process,<br class="">instead of making advantage of `@NSCopying` attribute, I have to<br class="">invoke the `copy()` method manually:<br class=""><br class="">```<br class="">init( employee externalEmployee: Person ) {<br class=""> &nbsp;// ...<br class=""> &nbsp;self.employee = externalEmployee.copy() as! Person &nbsp;<br class=""> &nbsp;// ...<br class=""> &nbsp;}<br class="">```<br class=""><br class="">In fact, what really makes me confusing is that `@NSCopying` semantic<br class="">does work properly within the other parts of the class definition such<br class="">as normal instance methods, or external scope. For instance, if we're<br class="">assigning an external instance of `Person` to the `self.employee` proper<br class="">of `Department` directly through setter rather than initializer:<br class=""><br class=""><blockquote type="cite" class="">department.employee = johnAppleseed<br class=""></blockquote><br class="">then `self.employee` property and `johnAppleseed` variable will no<br class="">longer share the same underlying object now. In the other words,<br class="">`@NSCopying` attribute makes sense.<br class=""><br class="">After I looked through a great deal of results given by Google, and<br class="">dicussions on StackOverflow, I finally found nothing related — the vast<br class="">majority of articles, documentations as well as issues talking about<br class="">this similar topics only focus on the basic concepts and effects of<br class="">`@NSCopying` itself but do not mentioned this strange behavior at all —<br class="">besides one radar descriping the same problem (<a href="rdar://21383959" class="">rdar://21383959</a>) and a<br class="">final conclusion mentioned in a guy's Gist comment: **... values set<br class="">during initialization are not cloned ...**<br class=""><br class="">That is, `@NSCopying` semantic has no effect in initializers.<br class=""><br class="">Then, what I want to figure out is the reason why `@NSCopying` semantic<br class="">will become effectless implicitly whithin initializers of a class, and<br class="">the special considerations behind this behavior, if any.<br class=""><br class="">Thank you very much.<br class=""><br class="">Best Regards,<br class="">Torin Kwok<br class=""><br class="">_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-users<br class=""></div></div></blockquote></div><br class=""></body></html>