[swift-evolution] guard let x = x

[Erica Sadun]

> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hey all,
> 
> As usual, apologies if this horse was beaten ages ago before I joined the mailing list, but thought I would bring this up.
> 
> 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:
> 
> guard let x, y, z else {…}
> 
> 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.
> 
> 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.
> 
> Any thoughts?
> 
> -d

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. 

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:

guard bind x, bind y, bind z else { ... }

"The bind thread" was discussed during the first week of February 2016. Joe Groff had said: "If you all are serious about this, I think you should start a new thread about it."  I thought it was worth a serious discussion just so it could be evaluated and either adopted or discarded and dropped forever. The arguments for:

* Simplifying an mildly complex and potentially misleading statement 
* Creating a deliberate and controlled rather than accidental shadowing style

The discussion petered out, with Kevin Ballard making the strongest case against: "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."

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.

-- E


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161026/83def005/attachment.html>