On Mon, Oct 31, 2016 at 8: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.)
>
I think we'd have some weirdness. For instance:
```
guard x != nil || x == y else { break }
// oops, now x isn't unwrapped anymore because I added a condition
```
Also, it'd be unexpected for it to be blessed for guard but not if:
```
if x != nil {
// is x unwrapped here?
// if so, this would be source-breaking...
// if not, it would be surprisingly inconsistent
}
```
> -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
