[swift-evolution] guard let x = x

[ilya]

> a) guard let foobar = foobar else { … }
> b) guard unwrap foobar else { … }

I would argue for
c) guard let reallyFoobar = foobar else { … }

(or perhaps guard let foobar_ = foobar else { … } )

That way one can use both an optional foobar and non-optional "unwrapped
value of foobar at the moment of guard" without any possibility of mixing
those two (and without violating DRY).

Ilya.

On Wed, Oct 26, 2016 at 6:38 PM Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> On Oct 26, 2016, at 8:58 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> 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.
>
>
> Yes, this has thoroughly been beaten to death.  It is also outside the
> scope of Swift 4 stage 1.  That said, it is such a glaring problem that
> we’ll have to deal with it at some point.
>
> 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 {…}
>
>
> This specific syntax is commonly requested.  The problem with this is that
> it provides no useful information about what is actually going on: it
> sacrifices clarity to get terseness, a specific non-goal of Swift.
>
>
> Erica says:
>
> 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 { … }
>
>
> To me, this is the most promising direction, but I’d suggest the use of
> “unwrap" as the keyword.  If you compare these two:
>
> a) guard let foobar = foobar else { … }
> b) guard unwrap foobar else { … }
>
> I think that b) wins by virtue of eliminating repetition ("foobar =
> foobar" fails DRY principles), but retains clarity by introducing a word
> into the grammar that people already commonly know and use, and which is
> googlable if they don’t.
>
> This also gives us the conceptual hook to make the “unwrapping an
> optional” behavior (which occurs with if let, optional chaining, etc) be
> something that could be extended to other similar user defined types, such
> as a Result type.
>
> -Chris
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161101/e24774be/attachment.html>