> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
