<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="">I do not see any necessity in a bind keyword and I don’t believe that it adds any clarity to the language. Furthermore, the current syntax allows one to change the variable name or add additional conditions in transparent manner. I also like that the current syntax make it very obvious that a variable is declared within a local scope. Flow-typing already exists in Swift (via as?) and while it might be a bit more verbose, its also more flexible. <div class=""><br class=""></div><div class="">However, I do agree that the specific semantic of let and var in the if context is a bit unexpected. So maybe one should look into making the optional unwrapping semantics more explicit. E.g. what about changing the semantics of ! so that it can be safely used in a conditional context? E.g.</div><div class=""><br class=""></div><div class="">if let x = x! {</div><div class=""><br class=""></div><div class="">}</div><div class=""><br class=""></div><div class="">if let x = x as! SomeType {</div><div class=""><br class=""></div><div class="">}</div><div class=""><br class=""></div><div class="">This would make it very clear that the value is being unwrapped without adding a lot of clutter or additional effort. </div><div class=""><br class=""></div><div class="">Alternative options for making binding more explicit</div><div class=""><br class=""></div><div class="">if let x ?= x </div><div class="">if let x ? x</div><div class="">if let? x = x</div><div class=""><br class=""></div><div class="">etc. But I do like the ! refinement above. </div><div class=""><br class=""></div><div class="">— Taras</div><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 02 Feb 2016, at 01:49, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I mostly agree with everything you said. I also think "if case" syntax is bad at the moment.<br class=""><div class=""><font face="monospace, monospace" class=""><br class=""></font></div>However I think any changes probably have to be an addition rather than a replacement.<div class=""><br class=""></div><div class="">I've tried to reconcile these changes with pattern matching and cannot work out how it fits. There's too many inconsistencies and incompatibilities. At best you can make a new pattern matching syntax that's incompatible with switch statements.<div class=""><div class=""><div class=""><br class="">On Tuesday, 2 February 2016, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> if bind foo {<br class="">
> // foo is non-optional in here<br class="">
> }<br class="">
<br class="">
If something in a flow control statement should read like an assertion, we don't want "bind" here.<br class="">
<br class="">
if has foo {<br class="">
// foo is non-optional<br class="">
}<br class="">
<br class="">
However, I do note that pattern matching in an if statement already lets you do the same thing as `if let` more explicitly:<br class="">
<br class="">
if case let foo? = bar {<br class="">
<br class="">
}<br class="">
<br class="">
I wonder if we should instead enhance this feature's usability. For instance, as a surgical change, we could drop the `case` keyword when `let` is present in the condition (since `let` isn't allowed in a boolean expression anyway):<br class="">
<br class="">
if let foo? = bar {<br class="">
<br class="">
}<br class="">
<br class="">
This is one character longer than the current `if let`, but it falls naturally out of other language features and allows for other similar constructs, like `if let .Success(value) = bar`.<br class="">
<br class="">
However, the `if case` syntax kind of sucks in other ways, too, and I think it deserves another look. In particular, the `=` isn't great for pattern matching that doesn't bind variables; people have complained about that part of `if case` before. Maybe we can improve that while still making the unwrapping good by introducing a keyword or operator that replaces the `=` while implying the `case` so it doesn't have to be stated explicitly. Here's a strawman of what this would look like, using `matches`:<br class="">
<br class="">
if let foo? matches bar<br class="">
if let .Success(value) matches bar<br class="">
if .Card(let rank, .Heart) matches bar<br class="">
if .OK matches bar<br class="">
<br class="">
Can we do this with `for case` too? Maybe...<br class="">
<br class="">
for let foo? matches in bars<br class="">
for let .Success(value) matches in bars<br class="">
for .Card(let rank, .Heart) matches in bars<br class="">
for .OK matches in bars<br class="">
<br class="">
I think this approach might work; the only question is what `matches` should be. I don't like using a keyword for it; I think it disappears too easily, particularly in the optional case. We do sort of have a pattern matching operator, `~=`, but it's very obscure, the overloading is not really right, and I can never remember which order the characters go in (possibly because Perl uses `=~` as its matching operator). Colon kind of reads well, but it disappears too easily, and it's already associated with typing:<br class="">
<br class="">
if let foo?: bar<br class="">
if let .Success(value): bar<br class="">
if .Card(let rank, .Heart): bar<br class="">
if .OK: bar<br class="">
<br class="">
I don't know what the answer is here, but I think this might be a good line to pursue.<br class="">
<br class="">
--<br class="">
Brent Royal-Gordon<br class="">
Architechies<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>
</div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>