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<T> 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 > > > -- > Rick Mann > rm...@latencyzero.com > > > _______________________________________________ > 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
