The benefit I see is that the logic internal to didSet blocks is often pretty generic in terms of how it deals with old VS new. <br><br>Eg:<br>* always bail if they match<br>* always render the new value<br>* always animate from the old value to the new value<br><br>The internal logic may repeat these names a lot, and it is unconcerned with the often lengthy or descriptive name that may be exposed to the outside world. <br><br>Often I rename the property, and have to rename 3 or 4 places inside the didSet which should in my view be unnecessary. <br><br>Conceptually this is similar to the benefit of having different internal and external parameter names for functions. In this case we have a great default internal parameter name available.<br><br>I'm not sure whether some good examples or some other form of reasoning best advances my point.<br><br>I'll try a sort of philosophical approach though. Why not have not didSet and willSet always both have newValue and oldValue, since keeping the API the same removes something the developer has to think about. In this way we actually simplify the language, since all change observing blocks have the same preconfigured variables available. <br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 27, 2016 at 12:47 AM Charlie Monroe <<a href="mailto:charlie@charliemonroe.net">charlie@charliemonroe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The newValue is already set in the property, so you just use that property. I don't see much benefit in having "newValue" instead of just accessing it:<br>
<br>
var anonymousUserMode = false {<br>
didSet {<br>
if oldValue == self.anonymousUserMode {<br>
return<br>
}<br>
<br>
renderLoginOverlay(show: newValue)<br>
}<br>
}<br>
<br>
And the same goes for willSet, where you have newValue, but not "oldValue", since oldValue is still in the stored property...<br>
<br>
> On Aug 26, 2016, at 8:20 PM, Eric Miller via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Just an idea.<br>
><br>
> I use didSet a lot, and it'd be nice to have a generic way to access the newValue.<br>
><br>
> For UI modes:<br>
><br>
> var anonymousUserMode = false { didSet {<br>
> if oldValue == anonymousUserMode { return }<br>
> renderLoginOverlay(show: anonymousUserMode)<br>
> }}<br>
><br>
> For animated display strings:<br>
><br>
> var errorMessage: String? = nil { didSet {<br>
> if oldValue == errorMessage { return }<br>
> errorLabel.text = errorMessage<br>
> // Do some sliding or hiding based on the new value<br>
> }}<br>
><br>
> Has the idea of using $0 / $1 or oldValue / newValue been considered?<br>
><br>
> I'd like to be able to write this as:<br>
><br>
> var anonymousUserMode = false { didSet {<br>
> if oldValue == newValue { return }<br>
> renderLoginOverlay(show: newValue)<br>
> }}<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote></div>