[swift-evolution] guard let x = x

[Kenny Leung]

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