<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 3, 2016, at 3:47 PM, Jordan Rose 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Data point (which Chris brought up already, I think?): We tried this* and got a <i class="">lot</i> of negative feedback. Optionals are unwrapped too often for people to be comfortable writing "if let name? = optionalCondition”.</div></div></div></blockquote><div><br class=""></div><div>Yes, I even implemented this and it was in the compiler for awhile, then later ripped it back out. You can find the history in git. I would guess that this all happened in ~March 2015.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">It may be more uniform and even more pedantically correct, but our users hated it.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div class="">* The actual thing we tried only allowed patterns that began with 'let', but that's close enough.</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 3, 2016, at 15:36, Brent Royal-Gordon 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 class="">This is a continuation of and alternative proposal to "The bind thread", which seems to have petered out without consensus.<br class=""><br class="">Currently there are three forms of `if` statement (and `guard` and `while`, but for simplicity I'll just say `if` throughout this discussion):<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if booleanCondition<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if let name = optionalCondition<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if case pattern = expression<br class=""><br class="">The boolean condition form is fine, but there are flaws in the other two. `if let` is unprincipled and doesn't really say what it does; `if case` is bulky and rarely used.* <br class=""><br class="">One very interesting thing about `if case`, too, is that it can actually do optional unwrapping:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if case let name? = optionalCondition<br class=""><br class="">This avoids the problems with `if let`—it's principled (it comes from a larger language feature) and it explicitly says it's handling optionality—but it still runs up against `if case`'s rarity and wordiness.<br class=""><br class="">So what I suggest is that we drop the `if let` form entirely and then drop the `case` keyword from `if case`. Pattern-matching conditions can still be distinguished from boolean conditions because boolean conditions can't contain an `=` operator. This, there would now only be two forms of if:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if booleanCondition<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if pattern = expression<br class=""><br class="">And the current `if let` is handled elegantly and clearly by existing pattern-matching shorthand, with only one additional character needed:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if let name? = optionalCondition<br class=""><br class="">I see two complications with this.<br class=""><br class="">The first is that, naively, `if let foo = bar` would still be valid, but would have different and vacuous behavior, since the pattern cannot fail to match. The compiler should probably emit an error or at least a warning when this happens.<br class=""><br class="">The second is our other weird use of the `case` keyword, `for case`, which is now an orphan in the language. I see several ways this could be handled:<br class=""><br class="">1. Drop the `for case` functionality entirely; if you want that behavior, use a pattern-matching `if`.<br class="">2. Replace the loop variable slot in the `for` statement with a pattern. This would force you to put `let` on all simple `for` statements.<br class="">3. Try to automatically distinguish between simple variables/tuples and patterns in this slot. What could possibly go wrong?<br class="">4. Require an equals sign before the `in`, like `for let foo? = in optionalFoos`. Looks a little gross, but it's unambiguous.<br class="">5. Replace `for case` with `for if`, like `for if let foo? in optionalFoos`. This helps flag the unusual conditional behavior of this form of `for`.<br class="">6. Just keep `for case` and don't worry about the fact that it's not parallel to the other statements anymore.<br class=""><br class="">Thoughts on any of this?<br class=""><br class=""><br class=""><br class="">* `if case` also has the problem that the `=` isn't appropriate unless you happen to bind some of the data matched by the pattern, but I don't know how to address that. A prior version of this proposal suggested saying `:=` instead of `=`, with the idea that `:=` could become a general pattern-matching operator, but the people I talked over this post with hated that.<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 href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></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=""></body></html>