<div dir="ltr">Scanning through our iOS project with ~600 Swift files we barely use `var` for function parameters or for if/guard statements.<div><br></div><div>I think the problems you outline should not be solved by using `var` but by making the code's intent much clearer by using distinct variable names.</div><div><br></div><div>In your example it is not clear what the purpose of the shadowed `rect` variable is. The same is true if you use `if var rect = …`:</div><div><br></div><div><div><font face="monospace, monospace">var selection = getRectangularSelection()</font></div><div><font face="monospace, monospace">if let rect = selection?.rect {</font></div><div><font face="monospace, monospace"> var rect = rect // what is rect used for? the variable name is quite generic</font></div><div><font face="monospace, monospace"> // mutate `rect` ...</font></div><div><div><font face="monospace, monospace"> // probably a lot of code</font></div><div><font face="monospace, monospace"> // …</font></div></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"> selection.rect = rect // what rect again?</font></div><div><font face="monospace, monospace">}</font></div></div><div><br></div><div>A better solution is to name the variables differently and make their intent very clear:</div><div><br></div><div><div><font face="monospace, monospace">var selection = getRectangularSelection()</font></div><div><font face="monospace, monospace">if let currentRect = selection?.rect {</font></div><div><font face="monospace, monospace"> var expandedRect = currentRect // intent becomes clear now</font></div><div><font face="monospace, monospace"> // expand `expandedRect` ...</font></div><div><font face="monospace, monospace"> // probably a lot of code</font></div><div><font face="monospace, monospace"> // …</font></div><div><font face="monospace, monospace"> </font></div><div><font face="monospace, monospace"> selection.rect = expandedRect // ah, THAT rect!</font></div><div><font face="monospace, monospace">}</font></div></div><div><br></div><div>So `if var` is really not necessary and causes more harm than good due to reduced clarity.</div><div><br></div><div>-1 for reversing the proposal from me.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 22, 2016 at 6:26 PM, David Farler via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone,<br>
<br>
I'd like to reconsider SE-0003 for Swift 3 and propose cancelling the change in its entirety. After collecting feedback since Swift's open source launch, I no longer feel this is a good move and there are a few reasons why.<br>
<br>
There are two main patterns that the removal penalizes:<br>
<br>
- Get-Modify-Reassign<br>
- Get-Modify-Return<br>
<br>
I've found that many of the problems with this proposal stem from the uses before and after the "Modify" part, before returning or reassigning with the new value.<br>
<br>
I've seen a few common responses to the var removal. Consider a `Rectangle` struct:<br>
<br>
<br>
struct Rectangle {<br>
var origin: (x: Double, y: Double)<br>
var size: (width: Double, height: Double)<br>
}<br>
<br>
<br>
Even with mutable variables `origin` and `size`, this pattern would be impossible:<br>
<br>
<br>
var selection = getRectangularSelection()<br>
if var rect = selection?.rect {<br>
// Mutate `rect` ...<br>
selection.rect = rect<br>
}<br>
<br>
<br>
So, one might shadow the variable, which is not ideal:<br>
<br>
<br>
var selection = getRectangularSelection()<br>
if let rect = selection?.rect {<br>
var rect = rect // Not so great<br>
// Mutate `rect` ...<br>
selection.rect = rect<br>
}<br>
<br>
<br>
Or, you might make a transformation function on `Rect`:<br>
<br>
<br>
struct Rectangle {<br>
var origin: (x: Double, y: Double)<br>
var size: (width: Double, height: Double)<br>
func withOrigin(x: Double, y: Double) -> Rect {<br>
var r = self<br>
r.origin = (x, y)<br>
return r<br>
}<br>
}<br>
<br>
<br>
This is a much better solution than shadowing but you would need one of these for any property that you want to mutate and I think you'll agree that it doesn't scale with the language we have today. This response begs for a kind of initializer that takes all of the fields of the original struct except any that you want to override:<br>
<br>
<br>
if let rect = selection?.rect.with(origin: newOrigin) {<br>
// ...<br>
}<br>
<br>
<br>
Straw syntax, but maybe you'll see something along these lines on swift-evolution in the future, which would provide a clear alternative to direct mutation patterns. Even then, I think having complementary patterns in the language isn't a bad thing.<br>
<br>
These problems come up with the other variable bindings but the one that ended up bothering me the most was `guard var`:<br>
<br>
<br>
func transform(selection: Rect?) {<br>
guard let rect = selection else { return }<br>
var _rect = rect<br>
// Mutate `_rect` ...<br>
}<br>
<br>
<br>
One of the guard statement's main purposes is to conditionally bind a value as a peer in its own scope, not an inner scope like if statements. Not having var makes the guard statement much weaker.<br>
<br>
There is certainly a bit of confusion about the nuances between value and reference semantics, who owns a value and when, how effects are propagated back to values, but I think we can attack the problem with more finesse.<br>
<br>
Value types are one of the attractive features of Swift – because of their semantics, mutating algorithms are written in a familiar style but keeping effects limited to your unique reference. I don't think we should give that up now to address confusion about semantics, out of principle, or in anticipation of new language features. I propose cancelling this change for Swift 3 and continue to allow `var` in the grammar everywhere it occurs in Swift 2.2.<br>
<br>
Regards,<br>
David<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
</blockquote></div><br></div>