> 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