[swift-evolution] guard let x = x

[Kenny Leung]

It seems to me that you would end up typing “guard unwrap” 99% of the time, so why not just let “guard” imply “guard unwrap” 100% of the time?

-Kenny


> On Oct 31, 2016, at 11:34 AM, Erica Sadun <erica at ericasadun.com> wrote:
> 
> Because there's an action taking place in addition to guarding
> 
> -- E
> 
>> On Oct 31, 2016, at 12:30 PM, Kenny Leung via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Why have the “unwrap” keyword at all? Isn’t “guard” the keyword?
>> 
>> guard blah else {
>> }
>> 
>> -Kenny
>> 
>> 
>>> On Oct 28, 2016, at 3:34 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>>> On Oct 26, 2016, at 11:39 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>>> On Oct 26, 2016, at 10:23 AM, Joshua Alvarado <alvaradojoshua0 at gmail.com> wrote:
>>>>> 
>>>>> In your example the keyword only makes sense if you are shadowing the optional variable. How would unwrap work with a different name?
>>>> 
>>>> It wouldn’t: “unwrap” would never include an equal sign.  If you want to do that, use a standard "if let”.
>>>> 
>>>> -Chris
>>> 
>>> So I can stop thinking about this. Gist is here: https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c
>>> 
>>> -- E
>>> 
>>> 
>>> Introducing unwrap
>>> 
>>> 	• Proposal: TBD
>>> 	• Author: Erica Sadun, Chris Lattner, David Goodine
>>> 	• Status: TBD
>>> 	• Review manager: TBD
>>> Introduction
>>> 
>>> This proposal introduces unwrap, simplifying common shadowing and allowing a unified syntax for one-item associated values such as Result types.
>>> 
>>> Swift-evolution thread: guard let x = x
>>> 
>>> Motivation
>>> 
>>> Swift lacks a unified, safe way to bind an optional or single-value enumeration to a shadowed varaiable that is guaranteed to be the same name. Introducing unwrap ensures the conditionally bound item does not accidentally shadow any other item. 
>>> 
>>> Compare:
>>> 
>>> guard let foobar = foobar else { …
>>> }
>>> 
>>> guard unwrap foobar else { … }
>>> Using unwrap eliminates repetition ("foobar = foobar" fails DRY principles) and retains clarity. The keyword is common, simple to understand, and easy to search for if Swift users are unfamiliar with it.
>>> 
>>> This syntax simplifies one-item associated value enumerations by offering a common syntax. Compare:
>>> 
>>> enum Result<T> { case success(T), error(Error
>>> ) }
>>> 
>>> 
>>> guard case let .success(value) = result else { ...
>>> }
>>> 
>>> guard unwrap result else { ... }
>>> In the latter case result is bound to the wrapped value. Again, it is simpler and clearer, even with non-Optional types.
>>> 
>>> Detailed Design
>>> 
>>> unwrap can be used with any one-value enumeration. The unwrapped value is bound to the same symbol as the associated type.
>>> 
>>> enum TypeName<T, U> { case anycase(T), anothercase(U) }
>>> 
>>> // First and second are type `TypeName`
>>> let first = TypeName.anyCase(value1)
>>> let second = TypeName. anothercase(value2)
>>> 
>>> guard unwrap first else { ... }
>>> // first is now shadowed as type T
>>> 
>>> guard unwrap second else { ... }
>>> // second is now shadowed as type U
>>> 
>>> Impact on Existing Code
>>> 
>>> This change is additive and has no impact on existing code other than intentional refactoring.
>>> 
>>> Timeline
>>> 
>>> This proposal is additive and not suited for consideration until Swift 4 phase 2
>>> 
>>> Alternatives Considered
>>> 
>>> 	• Using a bind keyword. Past discussions were held in the first week of February 2016.
>>> 	• Fixing pattern matching grammar
>>> 	• Not using this approach
>>> 
>>> _______________________________________________
>>> 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
>