<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I <i class="">still</i>&nbsp;don't understand how value types and reference types are different here. Here's a contrived "confusion" example (but we have seen similar real-world code):</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">for var element in array {</div><div class="">&nbsp; if element.isNotUpToMyStandards {</div><div class="">&nbsp; &nbsp; element = makeANewElement()</div><div class="">&nbsp; &nbsp; // 'element' is not stored back into 'array', but was meant to be.</div><div class="">&nbsp; }</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">This code, or rather the behavior the developer intended, is perfectly reasonable. But it's exactly the same code whether there's a value type or a reference type involved. I get that there are other examples where this is <i class="">not</i>&nbsp;the case, but I can't see how&nbsp;<i class="">those</i>&nbsp;would be any&nbsp;<i class="">less</i>&nbsp;confusing by adding this rule.</div><div class=""><br class=""></div><div class="">But maybe I'm just too familiar with Swift, and so have trouble putting myself in the shoes of a new learner.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 27, 2016, at 20:45 , J. Cheyo Jimenez &lt;<a href="mailto:cheyo@masters3d.com" class="">cheyo@masters3d.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">R<span style="font-size:12.8px" class="">eassigning of class objects probably occurs less than mutations&nbsp;of&nbsp;structs&nbsp;inside `if var` or `guard var`.</span><br class=""></div><div class=""><span style="font-size:12.8px" class="">The main reason for the removal of&nbsp;</span><span style="font-size:12.8px" class="">`if var` or `guard var`, AFAIK, is that people get confuse about references.&nbsp; Perhaps just limiting their use for value types could then clear up the confusion.&nbsp;</span></div><div class=""><span style="font-size:12.8px" class="">example of warning.&nbsp;</span></div><div class=""><span style="color:rgb(80,0,80);background-color:rgba(255,255,255,0)" class="">"'if var' is restricted to value types, did you mean 'if let'?"</span><br class=""></div><div class=""><font size="2" class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></font></div><div class="">One of the issues is that now all comma separated optionals need to be value types or offer alternative syntax.&nbsp;</div><div class=""><br class=""></div><div class="">if var value1 = value1, ref1 = ref1 {} /// This would not work</div><div class=""><br class=""></div><div class="">if var value1 = value1, let ref1 = ref1 {} /// Possible solution, notice the `let`<br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jan 27, 2016 at 8:05 PM, Jordan Rose <span dir="ltr" class="">&lt;<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>&gt;</span> wrote:<br class=""><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=""><div class="">That doesn't make sense to me. If it's sometimes necessary to reassign a struct containing a single reference, then surely it may be necessary to reassign a single reference not contained in a struct.</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Jordan</div></font></span><div class=""><div class="h5"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 26, 2016, at 20:37 , Nate Birkholz via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class=""><div class=""><div dir="auto" class=""><div class="">Seems in line with other compiler warnings.<br class=""><br class="">Sent from my iPhone, please excuse brevity and errors</div><div class=""><br class="">On Jan 26, 2016, at 8:30 PM, J. Cheyo Jimenez via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Would it be confusing if `guard var ` or &nbsp;`if var `&nbsp;<span class=""></span>was only allowed for value types?&nbsp;</div><br class=""><div class=""><br class="">On Tuesday, January 26, 2016, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
on Tue Jan 26 2016, Tian Zhang &lt;<a class="">swift-evolution@swift.org</a>&gt; wrote:<br class="">
<br class="">
&gt; I’m also curious how most people fix “guard var” or “if var”?<br class="">
&gt; Especially for checking a class object for protocol conformation and<br class="">
&gt; set variable on the object?<br class="">
&gt;<br class="">
&gt; like in this case,<br class="">
&gt;<br class="">
&gt;&gt; if var vc = vc as? ControlPanelConfigurationProtocol {<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;vc.servicePresentationObject = service<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;vc.presentAsPanel = true<br class="">
&gt;&gt; }<br class="">
&gt;<br class="">
&gt; become<br class="">
&gt;<br class="">
&gt;&gt; if let vc = vc as? ControlPanelConfigurationProtocol {<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;var vc = vc<br class="">
&gt;&gt;<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;vc.servicePresentationObject = service<br class="">
&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;vc.presentAsPanel = true<br class="">
&gt;&gt; }<br class="">
<br class="">
<br class="">
If vc has class type, you don't need the var at all.<br class="">
<br class="">
&gt; I saw a few people suggest to create a method on the protocol like<br class="">
&gt; “configureObject(...)” with all potential args and have the object to<br class="">
&gt; figure it out but doing so I feel we’re losing the benefits offered by<br class="">
&gt; property observation for the underlying object. Using pattern “if let”<br class="">
&gt; with a “var” in the block just to make the property mutable again<br class="">
&gt; feels really strange.<br class="">
&gt;<br class="">
&gt; Best Wishes,<br class="">
&gt; Tian<br class="">
&gt;&gt; An alternative would certainly be interesting but I would prefer to<br class="">
&gt;&gt; take it one step at a time and avoid being hasty so we can come up<br class="">
&gt;&gt; with something really great. What did most of your var fixes look<br class="">
&gt;&gt; like, by the way? Did you end up changing the layout of your value<br class="">
&gt;&gt; types or did you decide to add more vars?<br class="">
&gt;&gt;<br class="">
&gt;&gt; David<br class="">
&gt;&gt;<br class="">
&gt;&gt; &gt; On Jan 24, 2016, at 7:19 PM, Zach Waldowski via swift-evolution<br class="">
&gt;&gt; &gt; &lt;swift-evolution at <a href="http://swift.org/" target="_blank" class="">swift.org</a><br class="">
&gt;&gt; &gt; &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>&gt;&gt; wrote:<br class="">
&gt;&gt; &gt;<br class="">
&gt;&gt; &gt; -1<br class="">
&gt;&gt; &gt;<br class="">
&gt;&gt; &gt; Having already adopted the syntax in my projects in anticipation of 2.2,<br class="">
&gt;&gt; &gt; the increase in clarity at the expense of terseness is appreciated. A<br class="">
&gt;&gt; &gt; proposal should not be discussing an alternative, not a rollback.<br class="">
&gt;&gt; &gt;<br class="">
&gt;&gt; &gt; Cheers!<br class="">
&gt;&gt; &gt; Zachary Waldowski<br class="">
&gt;&gt; &gt; zach at <a href="http://waldowski.me/" target="_blank" class="">waldowski.me</a> &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>&gt;<br class="">
&gt;&gt; &gt;<br class="">
&gt;&gt; &gt; On Fri, Jan 22, 2016, at 12:26 PM, David Farler via swift-evolution<br class="">
&gt;&gt; &gt; wrote:<br class="">
&gt;&gt; &gt;&gt; Hello everyone,<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; I'd like to reconsider SE-0003 for Swift 3 and propose cancelling the<br class="">
&gt;&gt; &gt;&gt; change in its entirety. After collecting feedback since Swift's open<br class="">
&gt;&gt; &gt;&gt; source launch, I no longer feel this is a good move and there are a few<br class="">
&gt;&gt; &gt;&gt; reasons why.<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; There are two main patterns that the removal penalizes:<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; - Get-Modify-Reassign<br class="">
&gt;&gt; &gt;&gt; - Get-Modify-Return<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; I've found that many of the problems with this proposal stem from the<br class="">
&gt;&gt; &gt;&gt; uses before and after the "Modify" part, before returning or reassigning<br class="">
&gt;&gt; &gt;&gt; with the new value.<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; I've seen a few common responses to the var removal. Consider a<br class="">
&gt;&gt; &gt;&gt; `Rectangle` struct:<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; struct Rectangle {<br class="">
&gt;&gt; &gt;&gt; var origin: (x: Double, y: Double)<br class="">
&gt;&gt; &gt;&gt; var size: (width: Double, height: Double)<br class="">
&gt;&gt; &gt;&gt; }<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; Even with mutable variables `origin` and `size`, this pattern would be<br class="">
&gt;&gt; &gt;&gt; impossible:<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; var selection = getRectangularSelection()<br class="">
&gt;&gt; &gt;&gt; if var rect = selection?.rect {<br class="">
&gt;&gt; &gt;&gt; // Mutate `rect` ...<br class="">
&gt;&gt; &gt;&gt; selection.rect = rect<br class="">
&gt;&gt; &gt;&gt; }<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; So, one might shadow the variable, which is not ideal:<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; var selection = getRectangularSelection()<br class="">
&gt;&gt; &gt;&gt; if let rect = selection?.rect {<br class="">
&gt;&gt; &gt;&gt; var rect = rect // Not so great<br class="">
&gt;&gt; &gt;&gt; // Mutate `rect` ...<br class="">
&gt;&gt; &gt;&gt; selection.rect = rect<br class="">
&gt;&gt; &gt;&gt; }<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; Or, you might make a transformation function on `Rect`:<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; struct Rectangle {<br class="">
&gt;&gt; &gt;&gt; var origin: (x: Double, y: Double)<br class="">
&gt;&gt; &gt;&gt; var size: (width: Double, height: Double)<br class="">
&gt;&gt; &gt;&gt; func withOrigin(x: Double, y: Double) -&gt; Rect {<br class="">
&gt;&gt; &gt;&gt;&nbsp; &nbsp;var r = self<br class="">
&gt;&gt; &gt;&gt;&nbsp; &nbsp;r.origin = (x, y)<br class="">
&gt;&gt; &gt;&gt;&nbsp; &nbsp;return r<br class="">
&gt;&gt; &gt;&gt; }<br class="">
&gt;&gt; &gt;&gt; }<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; This is a much better solution than shadowing but you would need one of<br class="">
&gt;&gt; &gt;&gt; these for any property that you want to mutate and I think you'll agree<br class="">
&gt;&gt; &gt;&gt; that it doesn't scale with the language we have today. This response begs<br class="">
&gt;&gt; &gt;&gt; for a kind of initializer that takes all of the fields of the original<br class="">
&gt;&gt; &gt;&gt; struct except any that you want to override:<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; if let rect = selection?.rect.with(origin: newOrigin) {<br class="">
&gt;&gt; &gt;&gt; // ...<br class="">
&gt;&gt; &gt;&gt; }<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; Straw syntax, but maybe you'll see something along these lines on<br class="">
&gt;&gt; &gt;&gt; swift-evolution in the future, which would provide a clear alternative to<br class="">
&gt;&gt; &gt;&gt; direct mutation patterns. Even then, I think having complementary<br class="">
&gt;&gt; &gt;&gt; patterns in the language isn't a bad thing.<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; These problems come up with the other variable bindings but the one that<br class="">
&gt;&gt; &gt;&gt; ended up bothering me the most was `guard var`:<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; func transform(selection: Rect?) {<br class="">
&gt;&gt; &gt;&gt; guard let rect = selection else { return }<br class="">
&gt;&gt; &gt;&gt; var _rect = rect<br class="">
&gt;&gt; &gt;&gt; // Mutate `_rect` ...<br class="">
&gt;&gt; &gt;&gt; }<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; One of the guard statement's main purposes is to conditionally bind a<br class="">
&gt;&gt; &gt;&gt; value as a peer in its own scope, not an inner scope like if statements.<br class="">
&gt;&gt; &gt;&gt; Not having var makes the guard statement much weaker.<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; There is certainly a bit of confusion about the nuances between value and<br class="">
&gt;&gt; &gt;&gt; reference semantics, who owns a value and when, how effects are<br class="">
&gt;&gt; &gt;&gt; propagated back to values, but I think we can attack the problem with<br class="">
&gt;&gt; &gt;&gt; more finesse.<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; Value types are one of the attractive features of Swift – because of<br class="">
&gt;&gt; &gt;&gt; their semantics, mutating algorithms are written in a familiar style but<br class="">
&gt;&gt; &gt;&gt; keeping effects limited to your unique reference. I don't think we should<br class="">
&gt;&gt; &gt;&gt; give that up now to address confusion about semantics, out of principle,<br class="">
&gt;&gt; &gt;&gt; or in anticipation of new language features. I propose cancelling this<br class="">
&gt;&gt; &gt;&gt; change for Swift 3 and continue to allow `var` in the grammar everywhere<br class="">
&gt;&gt; &gt;&gt; it occurs in Swift 2.2.<br class="">
&gt;&gt; &gt;&gt;<br class="">
&gt;&gt; &gt;&gt; Regards,<br class="">
&gt;&gt; &gt;&gt; David<br class="">
&gt;&gt; &gt;&gt; _______________________________________________<br class="">
&gt;&gt; &gt;&gt; swift-evolution mailing list<br class="">
&gt;&gt; &gt;&gt; swift-evolution at <a href="http://swift.org/" target="_blank" class="">swift.org</a> &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>&gt;<br class="">
&gt;&gt; &gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
&gt;&gt; &gt;&gt; &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>&gt;<br class="">
&gt;&gt; &gt; _______________________________________________<br class="">
&gt;&gt; &gt; swift-evolution mailing list<br class="">
&gt;&gt; &gt; swift-evolution at <a href="http://swift.org/" target="_blank" class="">swift.org</a> &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>&gt;<br class="">
&gt;&gt; &gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
&gt;&gt; &gt; &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>&gt;<br class="">
&gt; _______________________________________________<br class="">
&gt; swift-evolution mailing list<br class="">
&gt; <a class="">swift-evolution@swift.org</a><br class="">
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
--<br class="">
-Dave<br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>