[swift-evolution] guard let x = x

[Nicholas Maccharoli]

Sorry I wrote that last email off a little too fast, my head was still
stuck in legacy Swift land.

by `if let a = a, b = b, c = c { ... }` I meant to say `if let a = a, let b
= b, let c = c { ... }`

And here:

> 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 { ... }`

I meant to say

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

Sorry!

On Tue, Nov 1, 2016 at 6:18 PM, Muse M via swift-evolution <
swift-evolution at swift.org> wrote:

> 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> 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
>>>
>>
>>
> _______________________________________________
> 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/a12821cb/attachment.html>