Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Chris Lattner via swift-evolution]

> On Dec 4, 2016, at 5:32 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Dec 4, 2016, at 4:31 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>> On Dec 3, 2016, at 7:06 PM, Erica Sadun  wrote:
>>> 
>>> 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.
>> 
>> For what it's worth, I don't agree that the default names are a problem. I 
>> think they're a helpful convenience which, nevertheless, must occasionally 
>> be overridden because they conflict with the name of something else. The 
>> names are well-chosen and virtually always read correctly.
>> 
>> (Also FWIW, I'm not sure I've ever explicitly named the 
>> `oldValue`/`newValue` variable rather than using the implicit names.)
>> 
>> I think a warning on using `oldValue` instead of `newValue` or vice versa 
>> would be very helpful and address the parts of this proposal which aren't 
>> motivated by mere style complaints. The rest I think is a style issue, and I 
>> don't think that style issue is nearly universally-agreed-upon or serious 
>> enough to motivate a breaking change affecting tons of property setters, 
>> property observers, and subscript setters.
> 
> +1

Just MHO, not speaking for the core team: +1 to Brent's points.

-Chris


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

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Matthew Johnson via swift-evolution]

Sent from my iPad

On Dec 4, 2016, at 4:31 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Dec 3, 2016, at 7:06 PM, Erica Sadun  wrote:
>> 
>> 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.
> 
> For what it's worth, I don't agree that the default names are a problem. I 
> think they're a helpful convenience which, nevertheless, must occasionally be 
> overridden because they conflict with the name of something else. The names 
> are well-chosen and virtually always read correctly.
> 
> (Also FWIW, I'm not sure I've ever explicitly named the `oldValue`/`newValue` 
> variable rather than using the implicit names.)
> 
> I think a warning on using `oldValue` instead of `newValue` or vice versa 
> would be very helpful and address the parts of this proposal which aren't 
> motivated by mere style complaints. The rest I think is a style issue, and I 
> don't think that style issue is nearly universally-agreed-upon or serious 
> enough to motivate a breaking change affecting tons of property setters, 
> property observers, and subscript setters.

+1

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] [Pitch] Removing Setter/Observer Name Overrides

[Brent Royal-Gordon via swift-evolution]

> On Dec 3, 2016, at 7:06 PM, Erica Sadun  wrote:
> 
> 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.

For what it's worth, I don't agree that the default names are a problem. I 
think they're a helpful convenience which, nevertheless, must occasionally be 
overridden because they conflict with the name of something else. The names are 
well-chosen and virtually always read correctly.

(Also FWIW, I'm not sure I've ever explicitly named the `oldValue`/`newValue` 
variable rather than using the implicit names.)

I think a warning on using `oldValue` instead of `newValue` or vice versa would 
be very helpful and address the parts of this proposal which aren't motivated 
by mere style complaints. The rest I think is a style issue, and I don't think 
that style issue is nearly universally-agreed-upon or serious enough to 
motivate a breaking change affecting tons of property setters, property 
observers, and subscript setters.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Jean-Daniel via swift-evolution]

Of course, I meaned

 set(newValue foo: valueType) {

}

> Le 4 déc. 2016 à 09:56, Jean-Daniel via swift-evolution 
>  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 
>> > a écrit :
>> 
>> [Original pitch: 
>> 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 
>>  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)) 
>>  
>>   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 >> 

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Jean-Daniel via swift-evolution]

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 
>  a écrit :
> 
> [Original pitch: 
> 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 
>  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)) 
>  
>   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 > > wrote:
>> 
>> I like this proposal!
>> 
>> +1
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Derrick Ho via swift-evolution]

True, adding the type would be redundant. Here is my revised solution.
Which basically still allows you do use a different name besides
newValue/oldValue

set { let temperature = newValue
// do stuff
}

didSet { let temperature = oldValue
// do stuff
}


On Sun, Dec 4, 2016 at 12:47 AM Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:

> oldValue is the value the property contained before didSet. self.value is
> the variable’s current value (i.e. newValue in willSet).
>
> Saagar Jha
>
>
>
> On Dec 3, 2016, at 9:34 PM, Rick Mann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> -1.
>
> I always name parameters to code blocks with an "in" or "out" prefix, and
> want to maintain my ability to change the name for set.
>
> As to oldValue, isn't that the same as self.value? Does it even need to
> exist?
>
> On Nov 30, 2016, at 14:40 , Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This pitch is breaking, and should be considered under the phase 1
> timeframe.
> gist here: https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b
>
> As usual, I will update the gist with feedback. Please refer to gist
> rather than
> this email for the latest revisions.
>
> -- E
>
>
> Removing Setter/Observer Name Overrides
>
> • Proposal: TBD
> • Author: Erica Sadun
> • Status: TBD
> • Review manager: TBD
> Introduction
>
> This proposal removes setter and observer name overrides from the Swift
> programming language, limiting their use to the defaults of newValue and
> oldValue.
>
> Swift-evolution thread: TBD
>
> Motivation
>
> Swift setters and property observers supply predefined symbols that
> represent value arguments. These are newValue for set and willSet, and
> oldValue for didSet. These implicit names are always available -- you don't
> need to take any action to have access to them -- and they are instantly
> recognizable in context.
>
> Swift allows you to override newValue and oldValue by supplying a name in
> parentheses after the set/willSet/didSet keyword, for example:
>
> set
> (temperature) {
>
> // use temperature instead of newValue
> }
> This feature is an attractive nuisance for the following reasons:
>
> Preferring newValue and oldValue to custom names is consistent. Someone
> reading code needn't recognize a new and unfamiliar symbol in setter or
> observer context.
>
> Preferring newValue and oldValue to custom names avoids errors. Some
> developers prefer to name all mentioned values for the sake of consistency,
> clarity, and readability like this:
>
> set(newValue) {...}
> Developers who follow this rule may accidentally insert newValue or
> oldValue in the wrong observer. It is not that uncommon. (See this tweet,
> for example.) Swift does not check for name mismatches, specifically for
> the common error of using oldValue in place of newValue or vice versa.
>
> Detailed Design
>
> Upon adopting this proposal:
>
> • Swift removes name overrides from the language.
> • Swift allows the current grammar to be used but disallows the mention of
> any mismatched name:
> set { ... } // okay
> willSet { ... } // okay
> didSet { ... } // okay
> set(newValue) { ... } // okay, self-documenting
> set(oldValue) { ... } // compiler error
> willSet(newValue) { ... } // okay, self-documenting
> willSet(oldValue) { ... } // compiler error
> didSet(oldValue) { ... } // okay, self-documenting
> didSet(newValue) { ... } // compiler error
> didSet(bob) { ... } // compiler error
> Type Members
>
> As an optional extra, Swift could emit warnings for any type member named
> newValue or oldValue.
>
> var newValue: T { ... } // warning
> A more extreme step would disallow the use of newValue and oldValue
> members, reserving those words for setters and observers. This proposal
> does not go so far since newValue and oldValue are reasonable property
> names for a generic ChangeSet struct.
>
> Although a warning could be limited to the presence of property observers
> and setters, this is not recommended. Deferring warnings until there's a
> name conflict might introduce the desire to rename members and break APIs
> when observers and setters are added at a later date. That outcome is
> undesirable.
>
> Please note that Swift properly differentiates between members
> (self.newValue) and the newValue argument, as in the following example.
>
> struct Foo
> {
>
> var newValue: Int = 0
>
>
> var observedMember: Int
> {
>
> willSet
> {
>
> print
> (newValue)
>
> // newValue = 100 // error, `newValue` is immutable
>self.newValue = 100
>
>}
>}
> }
>
>
> var test = Foo(newValue: 0, observedMember: 50
> )
> test.
> observedMember = 60 // prints 60
> test.newValue // 100
> Impact on Existing Code
>
> This proposal is breaking. The migrator will need to remove overrides and
> rename their mentions to newValue and oldValue.
>
> Timeline
>
> This proposal is breaking so needs to be considered in Swift 4 Stage 1
>
> Alternatives Considered
>
> • If this 

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Saagar Jha via swift-evolution]

oldValue is the value the property contained before didSet. self.value is the 
variable’s current value (i.e. newValue in willSet).

Saagar Jha



> On Dec 3, 2016, at 9:34 PM, Rick Mann via swift-evolution 
>  wrote:
> 
> -1.
> 
> I always name parameters to code blocks with an "in" or "out" prefix, and 
> want to maintain my ability to change the name for set.
> 
> As to oldValue, isn't that the same as self.value? Does it even need to exist?
> 
>> On Nov 30, 2016, at 14:40 , Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> This pitch is breaking, and should be considered under the phase 1 timeframe.
>> gist here: https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b
>> 
>> As usual, I will update the gist with feedback. Please refer to gist rather 
>> than 
>> this email for the latest revisions.
>> 
>> -- E
>> 
>> 
>> Removing Setter/Observer Name Overrides
>> 
>>  • Proposal: TBD
>>  • Author: Erica Sadun
>>  • Status: TBD
>>  • Review manager: TBD
>> Introduction
>> 
>> This proposal removes setter and observer name overrides from the Swift 
>> programming language, limiting their use to the defaults of newValue and 
>> oldValue. 
>> 
>> Swift-evolution thread: TBD
>> 
>> Motivation
>> 
>> Swift setters and property observers supply predefined symbols that 
>> represent value arguments. These are newValue for set and willSet, and 
>> oldValue for didSet. These implicit names are always available -- you don't 
>> need to take any action to have access to them -- and they are instantly 
>> recognizable in context.
>> 
>> Swift allows you to override newValue and oldValue by supplying a name in 
>> parentheses after the set/willSet/didSet keyword, for example:
>> 
>> set
>> (temperature) { 
>> 
>> // use temperature instead of newValue
>> }
>> This feature is an attractive nuisance for the following reasons:
>> 
>> Preferring newValue and oldValue to custom names is consistent. Someone 
>> reading code needn't recognize a new and unfamiliar symbol in setter or 
>> observer context. 
>> 
>> Preferring newValue and oldValue to custom names avoids errors. Some 
>> developers prefer to name all mentioned values for the sake of consistency, 
>> clarity, and readability like this:
>> 
>> set(newValue) {...}
>> Developers who follow this rule may accidentally insert newValue or oldValue 
>> in the wrong observer. It is not that uncommon. (See this tweet, for 
>> example.) Swift does not check for name mismatches, specifically for the 
>> common error of using oldValue in place of newValue or vice versa.
>> 
>> Detailed Design
>> 
>> Upon adopting this proposal:
>> 
>>  • Swift removes name overrides from the language.
>>  • Swift allows the current grammar to be used but disallows the mention 
>> of any mismatched name:
>> set { ... } // okay
>> willSet { ... } // okay
>> didSet { ... } // okay
>> set(newValue) { ... } // okay, self-documenting
>> set(oldValue) { ... } // compiler error
>> willSet(newValue) { ... } // okay, self-documenting
>> willSet(oldValue) { ... } // compiler error
>> didSet(oldValue) { ... } // okay, self-documenting
>> didSet(newValue) { ... } // compiler error
>> didSet(bob) { ... } // compiler error
>> Type Members
>> 
>> As an optional extra, Swift could emit warnings for any type member named 
>> newValue or oldValue. 
>> 
>> var newValue: T { ... } // warning
>> A more extreme step would disallow the use of newValue and oldValue members, 
>> reserving those words for setters and observers. This proposal does not go 
>> so far since newValue and oldValue are reasonable property names for a 
>> generic ChangeSet struct.
>> 
>> Although a warning could be limited to the presence of property observers 
>> and setters, this is not recommended. Deferring warnings until there's a 
>> name conflict might introduce the desire to rename members and break APIs 
>> when observers and setters are added at a later date. That outcome is 
>> undesirable.
>> 
>> Please note that Swift properly differentiates between members 
>> (self.newValue) and the newValue argument, as in the following example. 
>> 
>> struct Foo
>> {
>> 
>> var newValue: Int = 0
>> 
>> 
>> var observedMember: Int
>> {
>> 
>> willSet
>> {
>> 
>> print
>> (newValue)
>> 
>> // newValue = 100 // error, `newValue` is immutable
>>self.newValue = 100
>> 
>>}
>>}
>> }
>> 
>> 
>> var test = Foo(newValue: 0, observedMember: 50
>> )
>> test.
>> observedMember = 60 // prints 60
>> test.newValue // 100
>> Impact on Existing Code
>> 
>> This proposal is breaking. The migrator will need to remove overrides and 
>> rename their mentions to newValue and oldValue.
>> 
>> Timeline
>> 
>> This proposal is breaking so needs to be considered in Swift 4 Stage 1
>> 
>> Alternatives Considered
>> 
>>  • If this proposal is not adopted, Swift could still warn or error on  
>> set(oldValue), willSet(oldValue), and didSet(newValue), since 

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Saagar Jha via swift-evolution]

I’m along the lines of keeping the old behavior+warnings if “oldValue” is used 
for “newValue” and vice versa. Nonbreaking, and removes the issue of 
accidentally swapping the two.

Saagar Jha



> On Dec 3, 2016, at 7:33 PM, Derrick Ho via swift-evolution 
>  wrote:
> 
> I believe Erica's point about RIGHT NAMES ONLY is the most clear. While a 
> block-like syntax using $0 is nice, it fails to communicate whether it is a 
> newvalue or an oldvalue.
> 
> Therefore instead of following a block-like pattern it should follow a 
> delegate-function like pattern. This would remove the ambiguity that $0 or 
> name changing would present.
> 
> 
> set (newValue: TheType) {
> let a = newValue
> }
> 
> didSet (oldValue: TheType) {
> let b = oldValue
> }
> 

Hmm, why do we need “TheType”? Is this not conveyed by the actual property’s 
declaration?

> 
> 
> On Sat, Dec 3, 2016 at 10:06 PM Erica Sadun via swift-evolution 
> > wrote:
> [Original pitch: 
> 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 
>  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)) 
>  
>   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

Feels kind of “off”, since with closures the number represents a positional 
argument, but here the number has no value other than to match with closure 
syntax.

> 
> "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.)

+1 provided bug report is considered.

> 
> 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. 

-1, keeping “newValue” and “oldValue” is too restrictive, both in the case that 
there is another property with these names (causing potential confusion with 
self.newValue/self.oldValue), and in the case that the developer has a better 
description for the value.

> 
> RIGHT NAMES ONLY
> 
> Finally, the least popular design is my original 

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Rick Mann via swift-evolution]

-1.

I always name parameters to code blocks with an "in" or "out" prefix, and want 
to maintain my ability to change the name for set.

As to oldValue, isn't that the same as self.value? Does it even need to exist?

> On Nov 30, 2016, at 14:40 , Erica Sadun via swift-evolution 
>  wrote:
> 
> This pitch is breaking, and should be considered under the phase 1 timeframe.
> gist here: https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b
> 
> As usual, I will update the gist with feedback. Please refer to gist rather 
> than 
> this email for the latest revisions.
> 
> -- E
> 
> 
> Removing Setter/Observer Name Overrides
> 
>   • Proposal: TBD
>   • Author: Erica Sadun
>   • Status: TBD
>   • Review manager: TBD
> Introduction
> 
> This proposal removes setter and observer name overrides from the Swift 
> programming language, limiting their use to the defaults of newValue and 
> oldValue. 
> 
> Swift-evolution thread: TBD
> 
> Motivation
> 
> Swift setters and property observers supply predefined symbols that represent 
> value arguments. These are newValue for set and willSet, and oldValue for 
> didSet. These implicit names are always available -- you don't need to take 
> any action to have access to them -- and they are instantly recognizable in 
> context.
> 
> Swift allows you to override newValue and oldValue by supplying a name in 
> parentheses after the set/willSet/didSet keyword, for example:
> 
> set
> (temperature) { 
>
> // use temperature instead of newValue
> }
> This feature is an attractive nuisance for the following reasons:
> 
> Preferring newValue and oldValue to custom names is consistent. Someone 
> reading code needn't recognize a new and unfamiliar symbol in setter or 
> observer context. 
> 
> Preferring newValue and oldValue to custom names avoids errors. Some 
> developers prefer to name all mentioned values for the sake of consistency, 
> clarity, and readability like this:
> 
> set(newValue) {...}
> Developers who follow this rule may accidentally insert newValue or oldValue 
> in the wrong observer. It is not that uncommon. (See this tweet, for 
> example.) Swift does not check for name mismatches, specifically for the 
> common error of using oldValue in place of newValue or vice versa.
> 
> Detailed Design
> 
> Upon adopting this proposal:
> 
>   • Swift removes name overrides from the language.
>   • Swift allows the current grammar to be used but disallows the mention 
> of any mismatched name:
> set { ... } // okay
> willSet { ... } // okay
> didSet { ... } // okay
> set(newValue) { ... } // okay, self-documenting
> set(oldValue) { ... } // compiler error
> willSet(newValue) { ... } // okay, self-documenting
> willSet(oldValue) { ... } // compiler error
> didSet(oldValue) { ... } // okay, self-documenting
> didSet(newValue) { ... } // compiler error
> didSet(bob) { ... } // compiler error
> Type Members
> 
> As an optional extra, Swift could emit warnings for any type member named 
> newValue or oldValue. 
> 
> var newValue: T { ... } // warning
> A more extreme step would disallow the use of newValue and oldValue members, 
> reserving those words for setters and observers. This proposal does not go so 
> far since newValue and oldValue are reasonable property names for a generic 
> ChangeSet struct.
> 
> Although a warning could be limited to the presence of property observers and 
> setters, this is not recommended. Deferring warnings until there's a name 
> conflict might introduce the desire to rename members and break APIs when 
> observers and setters are added at a later date. That outcome is undesirable.
> 
> Please note that Swift properly differentiates between members 
> (self.newValue) and the newValue argument, as in the following example. 
> 
> struct Foo
>  {
> 
> var newValue: Int = 0
> 
> 
> var observedMember: Int
>  {
> 
> willSet
>  {
> 
> print
> (newValue)
> 
> // newValue = 100 // error, `newValue` is immutable
> self.newValue = 100
> 
> }
> }
> }
> 
> 
> var test = Foo(newValue: 0, observedMember: 50
> )
> test.
> observedMember = 60 // prints 60
> test.newValue // 100
> Impact on Existing Code
> 
> This proposal is breaking. The migrator will need to remove overrides and 
> rename their mentions to newValue and oldValue.
> 
> Timeline
> 
> This proposal is breaking so needs to be considered in Swift 4 Stage 1
> 
> Alternatives Considered
> 
>   • If this proposal is not adopted, Swift could still warn or error on  
> set(oldValue), willSet(oldValue), and didSet(newValue), since these can be 
> considered to be always wrong.
>   • Swift could entirely remove the parentheses syntax, although many 
> developers prefer to explicitly mention the magic argument names.
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Derrick Ho via swift-evolution]

I believe Erica's point about RIGHT NAMES ONLY is the most clear. While a
block-like syntax using $0 is nice, it fails to communicate whether it is a
newvalue or an oldvalue.

Therefore instead of following a block-like pattern it should follow a
delegate-function like pattern. This would remove the ambiguity that $0 or
name changing would present.


set (newValue: TheType) {
let a = newValue
}

didSet (oldValue: TheType) {
let b = oldValue
}



On Sat, Dec 3, 2016 at 10:06 PM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> [Original pitch:
> 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 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))
>   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  wrote:
>
> I like this proposal!
>
> +1
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Erica Sadun via swift-evolution]

[Original pitch: 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 
 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)) 
 
  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  wrote:
> 
> I like this proposal!
> 
> +1
> 

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

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Derrick Ho via swift-evolution]

I like this proposal!

+1

Oldvalue and newvalue have different meanings. I have witnesses programmers
overriding oldvalue with the name newvalue and vice versa.

Of course if you are good at reading the documentation then you would not
make the mistake.

Swift should be a language that prevents a programmer from making mistakes!

I am in favor of disallowing the name changes. Because it is much more
clear if it is an oldvalue or newvalue.

If a different name is desired there are two solutions, create a new
variable or add a capture list.

set (newValue: TheType) {
let temp = newValue
}

set { [temp = newValue] in

}

I think either of these would make this change easier to convert.

The second one would probably be easier to convert.

//current
set (temp) {

}

// Proposed and much more clear.
set { [temp = newValue] in

}

On Thu, Dec 1, 2016 at 3:01 PM Will Field-Thompson via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm also against this (though I like the first alternative about warning
> on set(oldValue) etc.).
>
> While I think there may be value in either preventing name overrides or
> requiring them here, I don't believe it's worth a breaking change. Then
> again, I have never personally encountered the problem (I tend not to
> override names), so maybe those who have feel differently.
>
> I also think that if this proposal goes through I would prefer not to
> allow the current name overriding syntax, even in the self-documenting
> case. At that point, the self-documenting case seems like unnecessary
> syntactic noise. It makes sense for a team where observer names are
> frequently overridden, but when that's disallowed, I feel that the
> self-documenting case adds very little.
>
> - Will
>
>
> On Thu, Dec 1, 2016 at 3:40 AM Tino Heth via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> -1
>
> I'm more or less neutral towards the change itself, but combined with the
> breaking effect, that's a clear "no".
>
> None the less, I hope that the whole topic with all its magic words
> (willSet, didSet, newValue, oldValue…) will be reworked in the future,
> which would be another argument not to fiddle with it now*
>
> - Tino
>
> *
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003148.html
> ___
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Will Field-Thompson via swift-evolution]

I'm also against this (though I like the first alternative about warning on
set(oldValue) etc.).

While I think there may be value in either preventing name overrides or
requiring them here, I don't believe it's worth a breaking change. Then
again, I have never personally encountered the problem (I tend not to
override names), so maybe those who have feel differently.

I also think that if this proposal goes through I would prefer not to allow
the current name overriding syntax, even in the self-documenting case. At
that point, the self-documenting case seems like unnecessary syntactic
noise. It makes sense for a team where observer names are frequently
overridden, but when that's disallowed, I feel that the self-documenting
case adds very little.

- Will

On Thu, Dec 1, 2016 at 3:40 AM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> -1
>
> I'm more or less neutral towards the change itself, but combined with the
> breaking effect, that's a clear "no".
>
> None the less, I hope that the whole topic with all its magic words
> (willSet, didSet, newValue, oldValue…) will be reworked in the future,
> which would be another argument not to fiddle with it now*
>
> - Tino
>
> *
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003148.html
> ___
> 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] [Pitch] Removing Setter/Observer Name Overrides

[Tino Heth via swift-evolution]

-1

I'm more or less neutral towards the change itself, but combined with the 
breaking effect, that's a clear "no".

None the less, I hope that the whole topic with all its magic words (willSet, 
didSet, newValue, oldValue…) will be reworked in the future, which would be 
another argument not to fiddle with it now*

- Tino

* 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003148.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Charles Srstka via swift-evolution]

Dramatically source-breaking, dubious benefit.

-1.

Charles

> On Nov 30, 2016, at 4:40 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> This pitch is breaking, and should be considered under the phase 1 timeframe.
> gist here: https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b 
> 
> 
> As usual, I will update the gist with feedback. Please refer to gist rather 
> than 
> this email for the latest revisions.
> 
> -- E
> 
> 
> Removing Setter/Observer Name Overrides
> 
> Proposal: TBD
> Author: Erica Sadun 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> This proposal removes setter and observer name overrides from the Swift 
> programming language, limiting their use to the defaults of newValue and 
> oldValue. 
> 
> Swift-evolution thread: TBD 
> 
>  
> Motivation
> 
> Swift setters and property observers supply predefined symbols that represent 
> value arguments. These are newValue for set and willSet, and oldValue for 
> didSet. These implicit names are always available -- you don't need to take 
> any action to have access to them -- and they are instantly recognizable in 
> context.
> 
> Swift allows you to override newValue and oldValue by supplying a name in 
> parentheses after the set/willSet/didSet keyword, for example:
> 
> set(temperature) { 
>// use temperature instead of newValue
> }
> This feature is an attractive nuisance for the following reasons:
> 
> Preferring newValue and oldValue to custom names is consistent. Someone 
> reading code needn't recognize a new and unfamiliar symbol in setter or 
> observer context. 
> 
> Preferring newValue and oldValue to custom names avoids errors. Some 
> developers prefer to name all mentioned values for the sake of consistency, 
> clarity, and readability like this:
> 
> set(newValue) {...}
> Developers who follow this rule may accidentally insert newValue or oldValue 
> in the wrong observer. It is not that uncommon. (See this tweet 
> , for example.) 
> Swift does not check for name mismatches, specifically for the common error 
> of using oldValue in place of newValue or vice versa.
> 
>  
> Detailed
>  Design
> 
> Upon adopting this proposal:
> 
> Swift removes name overrides from the language.
> Swift allows the current grammar to be used but disallows the mention of any 
> mismatched name:
> set { ... } // okay
> willSet { ... } // okay
> didSet { ... } // okay
> set(newValue) { ... } // okay, self-documenting
> set(oldValue) { ... } // compiler error
> willSet(newValue) { ... } // okay, self-documenting
> willSet(oldValue) { ... } // compiler error
> didSet(oldValue) { ... } // okay, self-documenting
> didSet(newValue) { ... } // compiler error
> didSet(bob) { ... } // compiler error
>  
> Type
>  Members
> 
> As an optional extra, Swift could emit warnings for any type member named 
> newValue or oldValue. 
> 
> var newValue: T { ... } // warning
> A more extreme step would disallow the use of newValue and oldValue members, 
> reserving those words for setters and observers. This proposal does not go so 
> far since newValue and oldValue are reasonable property names for a generic 
> ChangeSet struct.
> 
> Although a warning could be limited to the presence of property observers and 
> setters, this is not recommended. Deferring warnings until there's a name 
> conflict might introduce the desire to rename members and break APIs when 
> observers and setters are added at a later date. That outcome is undesirable.
> 
> Please note that Swift properly differentiates between members 
> (self.newValue) and the newValue argument, as in the following example. 
> 
> struct Foo {
> var newValue: Int = 0
> var observedMember: Int {
> willSet {
> print(newValue)
> // newValue = 100 // error, `newValue` is immutable
> self.newValue = 100
> }
> }
> }
> 
> var test = Foo(newValue: 0, observedMember: 50)
> test.observedMember = 60 // prints 60
> test.newValue // 100
>  
> Impact
>  on Existing Code
> 
> This proposal is breaking. The migrator will need to remove overrides and 
> rename their mentions to newValue and oldValue.
> 
>  
> Timeline
> 
> This proposal is breaking so needs to be considered in Swift 4 Stage 1
> 
>  
> 

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Brandon Knope via swift-evolution]

Breaking changes, at this point, have a high bar for acceptance. I am failing 
to see how the downsides presented here are enough to warrant a change. 

Also:
> Developers who follow this rule may accidentally insert newValue or oldValue 
> in the wrong observer. It is not that uncommon

One example from a tweet doesn't seem convincing enough that this is not an 
uncommon problem. Are there more examples of people getting hurt by this?

Brandon 

> On Nov 30, 2016, at 5:40 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Developers who follow this rule may accidentally insert newValue or oldValue 
> in the wrong observer. It is not that uncommon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Sean Heber via swift-evolution]

Perhaps an alternative would be to eliminate the newValue/oldValue magic names 
and require they be named in parens instead?

l8r
Sean


> On Nov 30, 2016, at 4:40 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> This pitch is breaking, and should be considered under the phase 1 timeframe.
> gist here: https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b
> 
> As usual, I will update the gist with feedback. Please refer to gist rather 
> than 
> this email for the latest revisions.
> 
> -- E
> 
> 
> Removing Setter/Observer Name Overrides
> 
>   • Proposal: TBD
>   • Author: Erica Sadun
>   • Status: TBD
>   • Review manager: TBD
> Introduction
> 
> This proposal removes setter and observer name overrides from the Swift 
> programming language, limiting their use to the defaults of newValue and 
> oldValue. 
> 
> Swift-evolution thread: TBD
> 
> Motivation
> 
> Swift setters and property observers supply predefined symbols that represent 
> value arguments. These are newValue for set and willSet, and oldValue for 
> didSet. These implicit names are always available -- you don't need to take 
> any action to have access to them -- and they are instantly recognizable in 
> context.
> 
> Swift allows you to override newValue and oldValue by supplying a name in 
> parentheses after the set/willSet/didSet keyword, for example:
> 
> set
> (temperature) { 
>
> // use temperature instead of newValue
> }
> This feature is an attractive nuisance for the following reasons:
> 
> Preferring newValue and oldValue to custom names is consistent. Someone 
> reading code needn't recognize a new and unfamiliar symbol in setter or 
> observer context. 
> 
> Preferring newValue and oldValue to custom names avoids errors. Some 
> developers prefer to name all mentioned values for the sake of consistency, 
> clarity, and readability like this:
> 
> set(newValue) {...}
> Developers who follow this rule may accidentally insert newValue or oldValue 
> in the wrong observer. It is not that uncommon. (See this tweet, for 
> example.) Swift does not check for name mismatches, specifically for the 
> common error of using oldValue in place of newValue or vice versa.
> 
> Detailed Design
> 
> Upon adopting this proposal:
> 
>   • Swift removes name overrides from the language.
>   • Swift allows the current grammar to be used but disallows the mention 
> of any mismatched name:
> set { ... } // okay
> willSet { ... } // okay
> didSet { ... } // okay
> set(newValue) { ... } // okay, self-documenting
> set(oldValue) { ... } // compiler error
> willSet(newValue) { ... } // okay, self-documenting
> willSet(oldValue) { ... } // compiler error
> didSet(oldValue) { ... } // okay, self-documenting
> didSet(newValue) { ... } // compiler error
> didSet(bob) { ... } // compiler error
> Type Members
> 
> As an optional extra, Swift could emit warnings for any type member named 
> newValue or oldValue. 
> 
> var newValue: T { ... } // warning
> A more extreme step would disallow the use of newValue and oldValue members, 
> reserving those words for setters and observers. This proposal does not go so 
> far since newValue and oldValue are reasonable property names for a generic 
> ChangeSet struct.
> 
> Although a warning could be limited to the presence of property observers and 
> setters, this is not recommended. Deferring warnings until there's a name 
> conflict might introduce the desire to rename members and break APIs when 
> observers and setters are added at a later date. That outcome is undesirable.
> 
> Please note that Swift properly differentiates between members 
> (self.newValue) and the newValue argument, as in the following example. 
> 
> struct Foo
>  {
> 
> var newValue: Int = 0
> 
> 
> var observedMember: Int
>  {
> 
> willSet
>  {
> 
> print
> (newValue)
> 
> // newValue = 100 // error, `newValue` is immutable
> self.newValue = 100
> 
> }
> }
> }
> 
> 
> var test = Foo(newValue: 0, observedMember: 50
> )
> test.
> observedMember = 60 // prints 60
> test.newValue // 100
> Impact on Existing Code
> 
> This proposal is breaking. The migrator will need to remove overrides and 
> rename their mentions to newValue and oldValue.
> 
> Timeline
> 
> This proposal is breaking so needs to be considered in Swift 4 Stage 1
> 
> Alternatives Considered
> 
>   • If this proposal is not adopted, Swift could still warn or error on  
> set(oldValue), willSet(oldValue), and didSet(newValue), since these can be 
> considered to be always wrong.
>   • Swift could entirely remove the parentheses syntax, although many 
> developers prefer to explicitly mention the magic argument names.
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___

[swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

[Erica Sadun via swift-evolution]

This pitch is breaking, and should be considered under the phase 1 timeframe.
gist here: https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b

As usual, I will update the gist with feedback. Please refer to gist rather 
than 
this email for the latest revisions.

-- E


Removing Setter/Observer Name Overrides

Proposal: TBD
Author: Erica Sadun 
Status: TBD
Review manager: TBD
 
Introduction

This proposal removes setter and observer name overrides from the Swift 
programming language, limiting their use to the defaults of newValue and 
oldValue. 

Swift-evolution thread: TBD 

 
Motivation

Swift setters and property observers supply predefined symbols that represent 
value arguments. These are newValue for set and willSet, and oldValue for 
didSet. These implicit names are always available -- you don't need to take any 
action to have access to them -- and they are instantly recognizable in context.

Swift allows you to override newValue and oldValue by supplying a name in 
parentheses after the set/willSet/didSet keyword, for example:

set(temperature) { 
   // use temperature instead of newValue
}
This feature is an attractive nuisance for the following reasons:

Preferring newValue and oldValue to custom names is consistent. Someone reading 
code needn't recognize a new and unfamiliar symbol in setter or observer 
context. 

Preferring newValue and oldValue to custom names avoids errors. Some developers 
prefer to name all mentioned values for the sake of consistency, clarity, and 
readability like this:

set(newValue) {...}
Developers who follow this rule may accidentally insert newValue or oldValue in 
the wrong observer. It is not that uncommon. (See this tweet 
, for example.) Swift 
does not check for name mismatches, specifically for the common error of using 
oldValue in place of newValue or vice versa.

 
Detailed
 Design

Upon adopting this proposal:

Swift removes name overrides from the language.
Swift allows the current grammar to be used but disallows the mention of any 
mismatched name:
set { ... } // okay
willSet { ... } // okay
didSet { ... } // okay
set(newValue) { ... } // okay, self-documenting
set(oldValue) { ... } // compiler error
willSet(newValue) { ... } // okay, self-documenting
willSet(oldValue) { ... } // compiler error
didSet(oldValue) { ... } // okay, self-documenting
didSet(newValue) { ... } // compiler error
didSet(bob) { ... } // compiler error
 
Type
 Members

As an optional extra, Swift could emit warnings for any type member named 
newValue or oldValue. 

var newValue: T { ... } // warning
A more extreme step would disallow the use of newValue and oldValue members, 
reserving those words for setters and observers. This proposal does not go so 
far since newValue and oldValue are reasonable property names for a generic 
ChangeSet struct.

Although a warning could be limited to the presence of property observers and 
setters, this is not recommended. Deferring warnings until there's a name 
conflict might introduce the desire to rename members and break APIs when 
observers and setters are added at a later date. That outcome is undesirable.

Please note that Swift properly differentiates between members (self.newValue) 
and the newValue argument, as in the following example. 

struct Foo {
var newValue: Int = 0
var observedMember: Int {
willSet {
print(newValue)
// newValue = 100 // error, `newValue` is immutable
self.newValue = 100
}
}
}

var test = Foo(newValue: 0, observedMember: 50)
test.observedMember = 60 // prints 60
test.newValue // 100
 
Impact
 on Existing Code

This proposal is breaking. The migrator will need to remove overrides and 
rename their mentions to newValue and oldValue.

 
Timeline

This proposal is breaking so needs to be considered in Swift 4 Stage 1

 
Alternatives
 Considered

If this proposal is not adopted, Swift could still warn or error on  
set(oldValue), willSet(oldValue), and didSet(newValue), since these can be 
considered to be always wrong.
Swift could entirely remove the parentheses syntax, although many developers 
prefer to explicitly mention the magic argument names.



___
swift-evolution mailing list