[swift-evolution] guard let x = x

[Nicholas Maccharoli]

I like the idea of drying up something like `guard let x = x, let y = y,
let z = z else { return }`
Using `guard unwrap` would surely be an improvement but still maybe
something like `guard unwrap x, unwrap y, unwrap x else { return }`
although very clear in intent is a bit bulky.

What about something like introducing a `given` / `given-where` clause for
`if` and `guard` ensuring an optional  is non-nil and shadowing the
variable with an unwrapped variable of the same name.

one way might be:

guard given a, b, c else { return }

or with an attached conditional:

guard given a, b, c where a > b else { return }

for dealing with long if-lets you could do something like:

if given a, b, c where a > b { ... }

Instead of if let a = a, b = b, c = c, a > b { ... }

The `where` clause does not need to be an actual keyword, it can just be a
trailing boolean expression but
maybe having it makes things like unwrapping and testing that a variable
evaluates to `true` more distinguishable.

something like `if given a, b, c, c { ... }` looks like it could be an
accidental typed repeat of `a` as much as it could mean `if given a, b, c,
c == true { ... }`

`if given a, b, c where c { ... }` might read a little easier.

Just a thought.

- Nick





On Tue, Nov 1, 2016 at 4:26 PM, Goffredo Marocchi via swift-evolution <
swift-evolution at swift.org> wrote:

> Agreed, a change like this would make sense :).
>
> Sent from my iPhone
>
> > On 1 Nov 2016, at 01:58, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> On Oct 31, 2016, at 6:46 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> >>
> >> On Mon, Oct 31, 2016 at 8:37 PM, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
> >> Sorry for piling onto the bikeshed. We do already have a notation for
> testing that an Optional isn't nil, `x != nil`. We could theoretically
> bless `<decl ref> != nil` as a statement condition to also unwrap the
> referenced declaration in the scope guarded by the condition. (`<decl ref>
> is T` could similarly rebind a declaration as the cast type.)
> >>
> >> I think we'd have some weirdness. For instance:
> >>
> >> ```
> >> guard x != nil || x == y else { break }
> >> // oops, now x isn't unwrapped anymore because I added a condition
> >> ```
> >>
> >> Also, it'd be unexpected for it to be blessed for guard but not if:
> >>
> >> ```
> >> if x != nil {
> >>  // is x unwrapped here?
> >>  // if so, this would be source-breaking...
> >>  // if not, it would be surprisingly inconsistent
> >> }
> >> ```
> >
> > `if` and `guard` share the same condition behavior. It's true that there
> would be limitations on when the unwrapping behavior applies, but QoI could
> potentially help. Users seem to be able to work within similar constraints
> in gradually-typed languages like Typescript that work similarly, and
> there's quite a lot of Swift users who are surprised at first that Swift
> doesn't behave similarly.
> >
> > -Joe
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> 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/5e3223ba/attachment.html>