[swift-evolution] guard let x = x

[Muse M]

In Rust lang, it uses .unwrap and b can be a non-nil variable.

guard a.unwrap, b, c.unwrap else {
}

On Tuesday, November 1, 2016, Nicholas Maccharoli via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>> >
>> >
>> >> On Oct 31, 2016, at 6:46 PM, Xiaodi Wu <xiaodi.wu at gmail.com
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> <javascript:_e(%7B%7D,'cvml','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/6ab5c8a3/attachment.html>