<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 Oct 26, 2016, at 5:40 AM, David Goodine 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="">Hey all,</div><div class=""><br class=""></div><div class="">As usual, apologies if this horse was beaten ages ago before I joined the mailing list, but thought I would bring this up.</div><div class=""><br class=""></div><div class="">I was typing the above (for the hundredth time) the other day and I was wondering whether it might be worth considering offering a shorter syntax:</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">guard let x, y, z else {…}</font></div><div class=""><br class=""></div>I was never convinced why implicit nil checks (i.e. if x {…}) were such a bad thing. But now in Swift it seems that it would be much more convenient to be able to simply skip the assignment part of the expression and define the above as guaranteeing and unwrapping x, y and z in the appropriate scope.<div class=""><br class=""></div><div class="">I think with such powerful and already compact expressions now wanting to get on the same line,adding this would make the language even more compact and elegant. It could be added as a non-source-breaking change, still allowing x = x for those who prefer it, but could significantly tighten up such uses, which I’m finding are ubiquitous in my code.</div><div class=""><br class=""></div><div class="">Any thoughts?</div><div class=""><br class=""></div><div class="">-d</div></div></div></blockquote><br class=""></div><div>There are safety arguments to be made for introducing a way to bind an optional to a shadowed variable that is guaranteed to be the same name ensuring the conditionally bound item does not accidentally shadow any other item. </div><div><br class=""></div><div>Your initial suggestion doesn't work as overloading "let" confuses rather than clarifies this process. In February, I brought up `bind x` to mean "conditionally bind x to x, and produce a conditional fail if that's not possible", with the hope that "bind self" could be used in closures. Under that scheme your example would read:</div><div><br class=""></div><div>guard bind x, bind y, bind z else { ... }</div><div><br class=""></div><div>"The bind thread" was discussed during the first week of February 2016. Joe Groff had said: <span style="font-family: Palatino-Roman;" class="">"</span><span style="font-family: Palatino-Roman;" class="">If you all are serious about this, I think you should start a new thread about it." </span><span style="font-family: Palatino-Roman;" class="">I thought it was worth a serious discussion just so it could be evaluated and either adopted or discarded </span><span style="font-family: Palatino-Roman;" class="">and dropped forever. The arguments for:</span></div><div><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div><div class="" style="font-family: Palatino-Roman;"><font face="Palatino-Roman" class="">* Simplifying an mildly complex and potentially misleading statement </font></div><div class="" style="font-family: Palatino-Roman;"><font face="Palatino-Roman" class="">* Creating a deliberate and controlled rather than accidental shadowing style</font></div><div class=""><br class=""></div></div><div><font face="Palatino-Roman" class="">The discussion petered out, with Kevin Ballard making the strongest case against: "</font><span style="font-family: Palatino-Roman;" class="">If your goal here is to just avoid having to write the `= foo`, then I disagree with the whole motive. If your goal here is to just use a keyword `bind` instead of `let` (e.g. if you want to use `if bind foo = foo { ... }`), I still disagree, because this new keyword serves no purpose. `if let foo = bar { ... }` is not "fundamentally different" than `let foo = bar`, it's still binding a new identifier to a value, the only difference is it binds it to an optional value. And it's really just a specialization of `if case let foo? = bar { ... }`. I've asked in the past about whether it's worth keeping the special case around now that we have `if case let` (or more specifically, if we should just turn `if let` into the generalized version, so you'd say `if let foo? = bar {... }`) and the answer from the core team was that they already tried it internally and found that the usage of optionals was so prevalent that the special-case optional-specific form of `if let` was worth keeping."</span></div><div><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div>There was not sufficient support to push forward with this, and reasonable arguments against. I'd suggest the long since beaten horse has moved on to a better world.</div><div><br class=""></div><div>-- E</div><div><br class=""></div><br class=""></body></html>