[swift-evolution] guard let x = x

[Erica Sadun]

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