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 <er...@ericasadun.com> wrote:
>
>
>> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution
>> <swift-evolution@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
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
