If you want to go to the side of consistency, why not just require the standard
method syntax like any other place ?
set(foo newValue: valueType) {
}
So old/newValue will become a parameter label.
> Le 4 déc. 2016 à 04:06, Erica Sadun via swift-evolution
> <[email protected]> a écrit :
>
> [Original pitch:
> https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b
> <https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b>]
>
> GENERAL FEEDBACK
>
> I received a gratifying amount of feedback about my pitch here, on Twitter,
> through email, on several Slack channels, and on IRC. I wanted to summarize
> the feedback, to start a new round of discussion.
>
> * A majority of respondents believe the current feature is incorrectly
> designed
> and that this is our best opportunity to change it.
> * A majority of respondents disagree on *how* it should be changed.
>
> Before I commit to the (non-trivial) effort of pushing on this, I'd like to
> know if any
> of the core team can chime in on the "preferred" design. Thank you.
>
> BUG REPORT
>
> The notion that the compiler should check for `set(oldValue)`,
> `willSet(oldValue)`,
> and `didSet(newValue)` and emit warnings or errors had pretty much universal
> support. I have submitted https://bugs.swift.org/browse/SR-3310
> <https://bugs.swift.org/browse/SR-3310> to address
> this, regardless of whether the syntax changes or not.
>
> MENTIONING NAMES
>
> A majority of respondents prefer that argument names always be mentioned,
> whether or not they *can* be omitted. Consensus is that it's unSwifty
> to use pre-built `newValue` and `oldValue` arguments without mentioning
> them first.
>
> * The current system violates the principle of clarity.
> * It adds too much magic (https://en.wikipedia.org/wiki/Magic_(programming))
> <https://en.wikipedia.org/wiki/Magic_(programming))>
> at the point of use.
> * It is inconsistent with the binding of variable names in closures.
>
> My original design, which I chose to provide the least impact on the compiler
> and
> existing code, was the least popular option.
>
> PREFERRED DESIGN
>
> The most popular design is that setters and property observers follow closures
> syntax, namely that the old value and new value arguments be passed as $0,
> and assignable using `name in`. Under this design, a setter looks like:
>
> ```
> set { newValue in ... } // or
> set { somethingElse in ... } // or
> set { use $0 here }
> ```
> Swift loses the "magic" newValue and oldValue, but any developer who
> normally prefers to mention the name before use has a simple, visible
> and easy way to retain that clarity.
>
> * Mirrors closure syntax
> * Easy to use
> * Loses magic names
> * Encourages documenting names in context
>
> "NO CHANGE"
>
> The second most popular design is "leave things as they are" (but implement
> the bug
> report.) Developers with good style habits will use mandatory `newValue` and
> `oldValue`
> names in their setter and observer declarations. No proposal is needed, and
> the bug
> report guards against potential errors.
>
> I would appreciate knowing whether the core team feels that the support for
> "no change",
> even from a smaller group of developers, disqualifies this issue from the
> high bar of Phase 1.
>
> (This group also included the most developers who self-reported that they did
> not
> use the override feature.)
>
> REMOVING OVERRIDES
>
> A third design entirely loses the ability to override variables or mention
> their names.
> This was in fact my *original* original design that I did not submit after
> sufficient
> devs told me they wanted to always spell out magic argument names.
>
> RIGHT NAMES ONLY
>
> Finally, the least popular design is my original pitch. (Only allow the
> "right" names,
> and allow them to be omitted.) This design has the least impact on the
> language,
> causes the least breaking for most use-cases, and allows most pro coders to
> continue
> using the "mention all names" approach.
>
> UPDATING PROPOSAL
>
> I am happy to update the proposal for the "closure-like" design. I believe
> there *was*
> reasonable consensus that the current system is out of step with Swift's
> design goals
> to push forward. However, I want this to go through another round of feedback.
>
> Thank you in advance for your comments. If this does move forward to a
> proposal, it
> must be discussed and decided in the first phase of Swift 4 as the change
> *is* breaking.
>
> -- Erica
>
>
>> On Dec 1, 2016, at 10:22 PM, Derrick Ho <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> I like this proposal!
>>
>> +1
>>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
