<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Seems in line with other compiler warnings.<br><br>Sent from my iPhone, please excuse brevity and errors</div><div><br>On Jan 26, 2016, at 8:30 PM, J. Cheyo Jimenez via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div>Would it be confusing if `guard var ` or `if var ` <span></span>was only allowed for value types? </div><br><div><br>On Tuesday, January 26, 2016, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Tue Jan 26 2016, Tian Zhang <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
<br>
> I’m also curious how most people fix “guard var” or “if var”?<br>
> Especially for checking a class object for protocol conformation and<br>
> set variable on the object?<br>
><br>
> like in this case,<br>
><br>
>> if var vc = vc as? ControlPanelConfigurationProtocol {<br>
>> vc.servicePresentationObject = service<br>
>> vc.presentAsPanel = true<br>
>> }<br>
><br>
> become<br>
><br>
>> if let vc = vc as? ControlPanelConfigurationProtocol {<br>
>> var vc = vc<br>
>><br>
>> vc.servicePresentationObject = service<br>
>> vc.presentAsPanel = true<br>
>> }<br>
<br>
<br>
If vc has class type, you don't need the var at all.<br>
<br>
> I saw a few people suggest to create a method on the protocol like<br>
> “configureObject(...)” with all potential args and have the object to<br>
> figure it out but doing so I feel we’re losing the benefits offered by<br>
> property observation for the underlying object. Using pattern “if let”<br>
> with a “var” in the block just to make the property mutable again<br>
> feels really strange.<br>
><br>
> Best Wishes,<br>
> Tian<br>
>> An alternative would certainly be interesting but I would prefer to<br>
>> take it one step at a time and avoid being hasty so we can come up<br>
>> with something really great. What did most of your var fixes look<br>
>> like, by the way? Did you end up changing the layout of your value<br>
>> types or did you decide to add more vars?<br>
>><br>
>> David<br>
>><br>
>> > On Jan 24, 2016, at 7:19 PM, Zach Waldowski via swift-evolution<br>
>> > <swift-evolution at <a href="http://swift.org" target="_blank">swift.org</a><br>
>> > <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a>>> wrote:<br>
>> ><br>
>> > -1<br>
>> ><br>
>> > Having already adopted the syntax in my projects in anticipation of 2.2,<br>
>> > the increase in clarity at the expense of terseness is appreciated. A<br>
>> > proposal should not be discussing an alternative, not a rollback.<br>
>> ><br>
>> > Cheers!<br>
>> > Zachary Waldowski<br>
>> > zach at <a href="http://waldowski.me" target="_blank">waldowski.me</a> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br>
>> ><br>
>> > On Fri, Jan 22, 2016, at 12:26 PM, David Farler via swift-evolution<br>
>> > wrote:<br>
>> >> Hello everyone,<br>
>> >><br>
>> >> I'd like to reconsider SE-0003 for Swift 3 and propose cancelling the<br>
>> >> change in its entirety. After collecting feedback since Swift's open<br>
>> >> source launch, I no longer feel this is a good move and there are a few<br>
>> >> 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<br>
>> >> uses before and after the "Modify" part, before returning or reassigning<br>
>> >> with the new value.<br>
>> >><br>
>> >> I've seen a few common responses to the var removal. Consider a<br>
>> >> `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<br>
>> >> 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<br>
>> >> these for any property that you want to mutate and I think you'll agree<br>
>> >> that it doesn't scale with the language we have today. This response begs<br>
>> >> for a kind of initializer that takes all of the fields of the original<br>
>> >> 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<br>
>> >> swift-evolution in the future, which would provide a clear alternative to<br>
>> >> direct mutation patterns. Even then, I think having complementary<br>
>> >> patterns in the language isn't a bad thing.<br>
>> >><br>
>> >> These problems come up with the other variable bindings but the one that<br>
>> >> 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<br>
>> >> value as a peer in its own scope, not an inner scope like if statements.<br>
>> >> Not having var makes the guard statement much weaker.<br>
>> >><br>
>> >> There is certainly a bit of confusion about the nuances between value and<br>
>> >> reference semantics, who owns a value and when, how effects are<br>
>> >> propagated back to values, but I think we can attack the problem with<br>
>> >> more finesse.<br>
>> >><br>
>> >> Value types are one of the attractive features of Swift – because of<br>
>> >> their semantics, mutating algorithms are written in a familiar style but<br>
>> >> keeping effects limited to your unique reference. I don't think we should<br>
>> >> give that up now to address confusion about semantics, out of principle,<br>
>> >> or in anticipation of new language features. I propose cancelling this<br>
>> >> change for Swift 3 and continue to allow `var` in the grammar everywhere<br>
>> >> it occurs in Swift 2.2.<br>
>> >><br>
>> >> Regards,<br>
>> >> David<br>
>> >> _______________________________________________<br>
>> >> swift-evolution mailing list<br>
>> >> swift-evolution at <a href="http://swift.org" target="_blank">swift.org</a> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br>
>> >> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>> >> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br>
>> > _______________________________________________<br>
>> > swift-evolution mailing list<br>
>> > swift-evolution at <a href="http://swift.org" target="_blank">swift.org</a> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br>
>> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>> > <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
--<br>
-Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>