[swift-evolution] guard let x = x

[Goffredo Marocchi]

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