> What is your evaluation of the proposal?
It’s clearly a concern and one that should be addressed.

A lot of people have bought up the didSet {} property observers are not called 
when things are set here, either. This is true, but unlike property observers, 
these are attributes, and I don’t know of anywhere else where an @attribute 
works in some cases and not in another. It is understandable that people think 
@NSCopying is implemented with compiler magic that should work everywhere, 
rather than built as part of the setter as it currently is, and thus causes 
confusion.

Like others have commented, I am concerned about how our solution works with 
future plans about making NSCopying a property behaviour. Doug Gregor has 
commented that he believes it should be compiler magic, and I respect that 
opinion. I would like the Core Team to ensure that they believe it is entirely 
compatible and in the spirit of Property Behaviours before the compiler magic 
is added, though, if Property Behaviours are still seriously on the cards for 
the future.

If compiler magic is decided against, I think this is a clear spot where there 
should be a warning, and a proposed fixit.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. This is a confusing and easily missed part of the language. While it is 
currently understood that didSet and willSet are not called, it is not clear to 
developers that @NSCopying falls into that same group, and have not noticed it 
anywhere in documentation.

> Does this proposal fit well with the feel and direction of Swift?
I think adding compiler magic is somewhat in opposition to the general trend to 
reduce said magic, but a solution here seems necessary as the current lack of 
clarity is against the direction of Swift.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
N/A

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A quick reading of the proposal, and involved in the initial discussions 
surrounding this issue.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to