A big YES to this! As long as "the scope guarded by the condition” means everything after the guard statement, and not everything inside an if statement.
-Kenny > On Oct 31, 2016, at 6:37 PM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > > 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
