Of course, I meaned
set(newValue foo: valueType) {
}
> Le 4 déc. 2016 à 09:56, Jean-Daniel via swift-evolution
> <swift-evolution@swift.org> a écrit :
>
> 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
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <wh1pch...@gmail.com
>>> <mailto:wh1pch...@gmail.com>> wrote:
>>>
>>> I like this proposal!
>>>
>>> +1
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
