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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

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

-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

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

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:

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

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

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

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

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

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