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@swift.org> wrote:
>
>
>> On Oct 31, 2016, at 6:46 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>
>> On Mon, Oct 31, 2016 at 8:37 PM, Joe Groff via swift-evolution
>> <swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
