[swift-evolution] guard let x = x

[David Goodine]

First off, Chris made it clear dealing with this isn't a priority for Swift 4 so take my comments (inline below) with a grain of salt. At least for the time being this horse should Rest In Peace. 

> On Oct 26, 2016, at 11:58 AM, Erica Sadun <erica at ericasadun.com> wrote:
> 
> 
>> 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. 
> 

Chris also raised this in a comment in this thread, and I agree with Swift's philosophy that terseness shouldn't compromise clarity of intent. 

What I don't get is why 'let x = x' is any clearer than the alternative I suggested. It's intent is only clear because the language defines it as such. In fact, I would argue that to programmers familiar with most other popular languages, it's intuitively unclear, even meaningless (except for being a rare reference to a 1980s Laurie Anderson song). 

I was simply suggesting that since neither is a familiar syntax, Swift could simple "define it as such" in a more compact (and as Chris pointed out, more DRY form).

That said, I do like your earlier proposal to introduce the 'bind' form (and agree with Chris that 'unwrap' would be clearer). Perhaps that's the way to go when it's time to tackle the issue. 

-d

(p.s. I'm still secretly trying to work a reference to the Dead Parrot sketch to issues like these. Perhaps one day...)

> 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/c2fded3b/attachment.html>