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.)
-Joe > On Oct 28, 2016, at 3:34 PM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Oct 26, 2016, at 11:39 AM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Oct 26, 2016, at 10:23 AM, Joshua Alvarado <alvaradojosh...@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@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