I have already submitted a new pull-request <https://github.com/apple/swift-evolution/pull/617> for this modification to the proposal SE-0153. Please you guys feel free to submit your review on GitHub's File Changed page <https://github.com/apple/swift-evolution/pull/617/files> or just reply this mail directly. Thank you.
> On 18 Feb 2017, at 19:57, Torin Kwok <to...@kwok.im> wrote: > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md> > Reply text: > > However, occasionally a constructor might be non-copying on purpose, so we'll > need a way to disable the warning. > How about the determination method mentioned in the proposal: > > ... if developers are performing an assignment operation from within an > initializer between a property declared as @NSCopyingand an instance of a > protocol conforming class. > That is, there are two key factors determining whether a fixable error or > warning should be emitted: > > If the destination property has been declared as @NSCopying in class > definition > If the source value conforms to <NSCopying> protocol > Once both are true, then what compiler can be sure about is that developer > definitely missed the required manual copy invocation and it would emit > either an error or a warning correspondingly. Otherwise, compiler would not > complain of anything and would just leave the decision up to developers. > > >> On 18 Feb 2017, at 18:16, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Feb 17, 2017, at 3:18 PM, Douglas Gregor <dgre...@apple.com >>> <mailto:dgre...@apple.com>> wrote: >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md >>> >>> <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? >> >> I think a warning is very appropriate. >> >> However, occasionally a constructor might be non-copying on purpose, so >> we'll need a way to disable the warning. A few possibilities: >> >> * Use .self on the value >> * Parenthesize the value >> * Parenthesize the variable >> >> I don't favor using compiler magic. Too spooky. >> >>> • Is the problem being addressed significant enough to warrant a change >>> to Swift? >> >> Yeah, that's a pretty easy mistake to make. >> >>> • Does this proposal fit well with the feel and direction of Swift? >> >> Yes. Swift usually tries to help you avoid mistakes. >> >>> • 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? >> >> Quick reading. >> >> -- >> Brent Royal-Gordon >> Architechies >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution