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<br><br>set { let temperature = newValue<br>// do stuff<br>}<br><br>didSet { let temperature = oldValue<br>// do stuff<br>}<br><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Dec 4, 2016 at 12:47 AM Saagar Jha via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">oldValue is the value the property contained before didSet. self.value is the variable’s current value (i.e. newValue in willSet).<div class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><span style="color:rgb(0,0,0);font-family:'SF UI Text';font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="gmail_msg">Saagar Jha</span><br style="color:rgb(0,0,0);font-family:'SF UI Text';font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><br style="color:rgb(0,0,0);font-family:'SF UI Text';font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><br style="color:rgb(0,0,0);font-family:'SF UI Text';font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">
</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">
<br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Dec 3, 2016, at 9:34 PM, Rick Mann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-8949550109905191619Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div class="gmail_msg">-1.<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">As to oldValue, isn't that the same as self.value? Does it even need to exist?<br class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg">On Nov 30, 2016, at 14:40 , Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg">This pitch is breaking, and should be considered under the phase 1 timeframe.<br class="gmail_msg">gist here: <a href="https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b" class="gmail_msg" target="_blank">https://gist.github.com/erica/f5c58c689a6f479606c6158077c1962b</a><br class="gmail_msg"><br class="gmail_msg">As usual, I will update the gist with feedback. Please refer to gist rather than <br class="gmail_msg">this email for the latest revisions.<br class="gmail_msg"><br class="gmail_msg">-- E<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Removing Setter/Observer Name Overrides<br class="gmail_msg"><br class="gmail_msg"><span class="m_-8949550109905191619Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>• Proposal: TBD<br class="gmail_msg"><span class="m_-8949550109905191619Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>• Author: Erica Sadun<br class="gmail_msg"><span class="m_-8949550109905191619Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>• Status: TBD<br class="gmail_msg"><span class="m_-8949550109905191619Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>• Review manager: TBD<br class="gmail_msg">Introduction<br class="gmail_msg"><br class="gmail_msg">This proposal removes setter and observer name overrides from the Swift programming language, limiting their use to the defaults of newValue and oldValue. <br class="gmail_msg"><br class="gmail_msg">Swift-evolution thread: TBD<br class="gmail_msg"><br class="gmail_msg">Motivation<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">Swift allows you to override newValue and oldValue by supplying a name in parentheses after the set/willSet/didSet keyword, for example:<br class="gmail_msg"><br class="gmail_msg">set<br class="gmail_msg">(temperature) { <br class="gmail_msg"><br class="gmail_msg">// use temperature instead of newValue<br class="gmail_msg">}<br class="gmail_msg">This feature is an attractive nuisance for the following reasons:<br class="gmail_msg"><br class="gmail_msg">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. <br class="gmail_msg"><br class="gmail_msg">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:<br class="gmail_msg"><br class="gmail_msg">set(newValue) {...}<br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">Detailed Design<br class="gmail_msg"><br class="gmail_msg">Upon adopting this proposal:<br class="gmail_msg"><br class="gmail_msg"><span class="m_-8949550109905191619Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>• Swift removes name overrides from the language.<br class="gmail_msg"><span class="m_-8949550109905191619Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>• Swift allows the current grammar to be used but disallows the mention of any mismatched name:<br class="gmail_msg">set { ... } // okay<br class="gmail_msg">willSet { ... } // okay<br class="gmail_msg">didSet { ... } // okay<br class="gmail_msg">set(newValue) { ... } // okay, self-documenting<br class="gmail_msg">set(oldValue) { ... } // compiler error<br class="gmail_msg">willSet(newValue) { ... } // okay, self-documenting<br class="gmail_msg">willSet(oldValue) { ... } // compiler error<br class="gmail_msg">didSet(oldValue) { ... } // okay, self-documenting<br class="gmail_msg">didSet(newValue) { ... } // compiler error<br class="gmail_msg">didSet(bob) { ... } // compiler error<br class="gmail_msg">Type Members<br class="gmail_msg"><br class="gmail_msg">As an optional extra, Swift could emit warnings for any type member named newValue or oldValue. <br class="gmail_msg"><br class="gmail_msg">var newValue: T { ... } // warning<br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">Please note that Swift properly differentiates between members (self.newValue) and the newValue argument, as in the following example. <br class="gmail_msg"><br class="gmail_msg">struct Foo<br class="gmail_msg"> {<br class="gmail_msg"><br class="gmail_msg">var newValue: Int = 0<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">var observedMember: Int<br class="gmail_msg"> {<br class="gmail_msg"><br class="gmail_msg">willSet<br class="gmail_msg"> {<br class="gmail_msg"><br class="gmail_msg">print<br class="gmail_msg">(newValue)<br class="gmail_msg"><br class="gmail_msg">// newValue = 100 // error, `newValue` is immutable<br class="gmail_msg"> self.newValue = 100<br class="gmail_msg"><br class="gmail_msg"> }<br class="gmail_msg"> }<br class="gmail_msg">}<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">var test = Foo(newValue: 0, observedMember: 50<br class="gmail_msg">)<br class="gmail_msg">test.<br class="gmail_msg">observedMember = 60 // prints 60<br class="gmail_msg">test.newValue // 100<br class="gmail_msg">Impact on Existing Code<br class="gmail_msg"><br class="gmail_msg">This proposal is breaking. The migrator will need to remove overrides and rename their mentions to newValue and oldValue.<br class="gmail_msg"><br class="gmail_msg">Timeline<br class="gmail_msg"><br class="gmail_msg">This proposal is breaking so needs to be considered in Swift 4 Stage 1<br class="gmail_msg"><br class="gmail_msg">Alternatives Considered<br class="gmail_msg"><br class="gmail_msg"><span class="m_-8949550109905191619Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>• 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.<br class="gmail_msg"><span class="m_-8949550109905191619Apple-tab-span gmail_msg" style="white-space:pre-wrap"> </span>• Swift could entirely remove the parentheses syntax, although many developers prefer to explicitly mention the magic argument names.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></blockquote><br class="gmail_msg"><br class="gmail_msg">-- <br class="gmail_msg">Rick Mann<br class="gmail_msg"><a href="mailto:rmann@latencyzero.com" class="gmail_msg" target="_blank">rmann@latencyzero.com</a><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></div></blockquote></div><br class="gmail_msg"></div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>