Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

[Rod Brown via swift-evolution]

> 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

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

[Torin Kwok via swift-evolution]

Hello Swift community:

Thank you for your reviews for my proposal. As you may have seen, this proposal 
contains two solutions originally:

Compiler magic
Compile-time checking
However even though Solution: Compiler magic is viable, according to some of 
feedback from several reviewers, a developer who is new to Swift would continue 
to be misled by the introduction of the automatic copy behavior:

from Xiaodi Wu xiaodi...@gmail.com :

A person who is new to Swift would continue to be confused if @NSCopying had 
magic but didSet and other behaviors did not. A person who has studied Swift 
and internalized the reasoning behind this initially tricky situation might 
rightly expect that all behaviors, including @NSCopying, are ignored during 
init.
from David Hart da...@hartbit.com :

For the same reasons as Xiaodi, this proposal could be potentially misleading 
if it introduces custom compiler magic, warning or errors that was not 
replicated for future property behaviours.
For this consideration, I decided to lower the priority of Solution: Compiler 
magic to Alternatives Considered section and leave Solution: Compile-time 
checking as the only one major solution, which suggests that compiler warns the 
developers to call copy manually, rather than implicit magic:

Have compiler emit a compile-time error or warning if developers are performing 
an assignment operation from within an initializer between a property declared 
as @NSCopying and an instance of a protocol conforming class.
I’ve already submitted a pull-request for this modification.

Best,

Torin

smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

[David Waite via swift-evolution]

> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md
>  
> 
> 
> What is your evaluation of the proposal?
Its an ugly problem. My preference would be to warn the developer to call copy 
manually for now, vs copy automatically. 

The reason I’m concerned about the automatic approach is that I do not know if 
property behaviors are something which may still appear in a future version of 
Swift. At that point, I would expect NSCopying to become a behavior, and not a 
special case for initializer code generation.

If property behaviors are not planned for any future version of swift, then I 
suppose I’m impartial to the solution.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
I think so; it won’t be clear to developers that initializers special-case 
property access, and silently going against their declared desired behavior is 
a bad idea.

> Does this proposal fit well with the feel and direction of Swift?
As stated above, I believe it depends on whether or not there is a future 
property behaviors spec that this would conflict with.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
In Ruby, the behavior is simpler - @foo will access the property value 
directly, while self.foo or some_reference.foo will use the ‘foo’ function. 
Dots are always used to invoke functions.

Objective C has a syntax for property access as well, in that you can refer to 
the synthesized property values directly via an underscore prefix. 

A syntax for direct property data access in swift would be a third way to solve 
the problem. In that case, it would be clearer to the developer what they 
needed to do.
 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

A quick reading

-DW

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

[David Hart via swift-evolution]

>> What is your evaluation of the proposal?

For the same reasons as Xiaodi, this proposal could be potentially misleading 
if it introduces custom compiler magic, warning or errors that was not 
replicated for future property behaviours. 

But at the same time, it's very easy for even a seasoned developer to always 
remember to do the right thing in initializers. Swift's safety goals should 
technically avoid such simple mistakes from being made.

So I'm torn, with a slight preference for accepting the proposal with the 
warning solution.

>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?

It's a safety concern that can avoid bugs in our code so I'd say it's 
significant enough.

>> Does this proposal fit well with the feel and direction of Swift?

Yes.

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

No.

>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?

Quick reading.

On 18 Feb 2017, at 02:05, Xiaodi Wu via swift-evolution 
 wrote:

>> What is your evaluation of the proposal?
> This document seems to propose two contradictory alternative solutions; I 
> assume the goal is that the core team will choose one of two. I'm not sure 
> that either is an improvement over the status quo, for reasons I outline 
> below.
>  
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> I agree that the current situation is problematic because of inconsistency, 
> but I think both proposed solutions are more problematic because of more 
> inconsistency.
>  
>> Does this proposal fit well with the feel and direction of Swift?
> On the one hand, I can agree that `@NSCopying` not being respected in 
> `init()` can be confusing. However, as was pointed out during the initial 
> pitch, this is consistent with other behaviors. For example, `didSet` is not 
> called from `init()` either, and there are good reasons for this. If the 
> proposal for custom behaviors were to come back into consideration, I would 
> assume that none of those behaviors could be triggered from `init()` either.
> 
> A person who is new to Swift would continue to be confused if `@NSCopying` 
> had magic but `didSet` and other behaviors did not. A person who has studied 
> Swift and internalized the reasoning behind this initially tricky situation 
> might rightly expect that _all_ behaviors, including `@NSCopying`, are 
> ignored during `init`.
> 
> The proposal seems to prioritize new users migrating from Obj-C, who are 
> unfamiliar with Swift idioms, over Swift users who are right to expect some 
> internal consistency in the language. While supporting both groups is 
> important, I'm not sure it's appropriate to increase inconsistency within 
> Swift itself to help with migration from Obj-C.
>  
>> 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.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

[Xiaodi Wu via swift-evolution]

>
>
>- What is your evaluation of the proposal?
>
> This document seems to propose two contradictory alternative solutions; I
assume the goal is that the core team will choose one of two. I'm not sure
that either is an improvement over the status quo, for reasons I outline
below.


>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> I agree that the current situation is problematic because of
inconsistency, but I think both proposed solutions are more problematic
because of more inconsistency.


>
>- Does this proposal fit well with the feel and direction of Swift?
>
> On the one hand, I can agree that `@NSCopying` not being respected in
`init()` can be confusing. However, as was pointed out during the initial
pitch, this is consistent with other behaviors. For example, `didSet` is
not called from `init()` either, and there are good reasons for this. If
the proposal for custom behaviors were to come back into consideration, I
would assume that none of those behaviors could be triggered from `init()`
either.

A person who is new to Swift would continue to be confused if `@NSCopying`
had magic but `didSet` and other behaviors did not. A person who has
studied Swift and internalized the reasoning behind this initially tricky
situation might rightly expect that _all_ behaviors, including
`@NSCopying`, are ignored during `init`.

The proposal seems to prioritize new users migrating from Obj-C, who are
unfamiliar with Swift idioms, over Swift users who are right to expect some
internal consistency in the language. While supporting both groups is
important, I'm not sure it's appropriate to increase inconsistency within
Swift itself to help with migration from Obj-C.


>
>- 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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution