[swift-evolution] guard let x = x

[Erica Sadun]

> 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 <https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c>

-- E


Introducing unwrap

Proposal: TBD
Author: Erica Sadun <https://github.com/erica>, Chris Lattner <https://github.com/lattner>, David Goodine
Status: TBD
Review manager: TBD
 <https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c#introduction>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 <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028440.html>
 <https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c#motivation>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 <https://en.wikipedia.org/wiki/Don%27t_repeat_yourself>) 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.

 <https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c#detailed-design>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
 <https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c#impact-on-existing-code>Impact on Existing Code

This change is additive and has no impact on existing code other than intentional refactoring.

 <https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c#timeline>Timeline

This proposal is additive and not suited for consideration until Swift 4 phase 2

 <https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c#alternatives-considered>Alternatives Considered

Using a bind keyword. Past discussions were held in the first week of February 2016 <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/thread.html>.
Fixing pattern matching grammar <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/tbd.html>
Not using this approach

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161028/a70b7a5d/attachment.html>