>> 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 <swift-evolution@swift.org> 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
