The proposal is to create a new shorthand "guard unwrap x" for "guard let x
= x". The "guard" statement serves purposes other than unwrapping variables
and cannot be removed.
On Mon, Oct 31, 2016 at 14:03 Joshua Alvarado <alvaradojosh...@gmail.com>
wrote:
> Without going back through the history, is the proposal to keep replace
> guard or still keep guard keyword and create a new unwrap? If unwrap is
> added the guard keyword should just be removed.
>
> Alvarado, Joshua
>
> On Oct 31, 2016, at 12:49 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Because "guard" already means something...
>
>
> On Mon, Oct 31, 2016 at 13:45 Kenny Leung via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It seems to me that you would end up typing “guard unwrap” 99% of the
> time, so why not just let “guard” imply “guard unwrap” 100% of the time?
>
> -Kenny
>
>
> > On Oct 31, 2016, at 11:34 AM, Erica Sadun <er...@ericasadun.com> wrote:
> >
> > Because there's an action taking place in addition to guarding
> >
> > -- E
> >
> >> On Oct 31, 2016, at 12:30 PM, Kenny Leung via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> 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@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
>
> _______________________________________________
> 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
