The hidden bugs arise when, instead of pill, you invoke pill(), and the
return value of pill() changes from Bool to Bool? or vice versa between one
version of a library and another.
Point is, a second keyword is needed precisely because unwrapping should
never be implicit. That much has been made clear in previous conversations
where "guard let x" has been repeatedly rejected as a sugar for "guard let
x = x". It stands to reason that "guard x" is even less acceptable.
On Mon, Oct 31, 2016 at 14:43 Kenny Leung via swift-evolution <
swift-evolution@swift.org> wrote:
> Now that I think about it some more, I think my proposal does not hurt the
> guard boolean case, and is still backward compatible.
>
> Current Universe:
>
> // This is the case Xiaodi mentions
> var pill :Boolean
> guard pill else {}
>
> // If pill was an optional-boolean, you would have to write it this way:
> var pill :Boolean?
> guard let pill = pill, pill else {}
>
> Kenny’s Universe:
>
> // This is the case Xiaodi mentions - nothing changes
> var pill :Boolean
> guard pill else{}
>
> // If pill was an optional-boolean, you might write this, but it only
> checks if pill is nil or not, and NOT true or false. This would be illegal
> in the Current Universe, so we know there is no backward incompatibility or
> hidden bugs.
> var pill :Boolean?
> guard pill else {}
>
> -Kenny
>
>
> > On Oct 31, 2016, at 12:33 PM, Kenny Leung via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I use guard pretty much exclusively in the “guard let x = x” context. I
> still think it’s a bad idea to sacrifice the 99% case for the 1% case.
> >
> > -Kenny
> >
> >
> >> On Oct 31, 2016, at 12:16 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Well, "guard x != nil" does not unwrap x. An additive proposal must
> make clear the difference between testing if an optional is nil and
> unwrapping it.
> >>
> >> Meanwhile, "guard foo" tests if foo evaluates to true. An additive
> proposal cannot break this syntax.
> >> On Mon, Oct 31, 2016 at 14:11 Charlie Monroe <char...@charliemonroe.net>
> wrote:
> >> To me, it makes more sense to use
> >>
> >> guard nonnil x else ...
> >>
> >> since guard is guarding a condition is true - or am I wrong? Generally,
> it would tell the compiler that
> >>
> >> guard x != nil else ...
> >>
> >> which to me reads like guard nonnil x...
> >>
> >> Just a side-note...
> >>
> >>> On Oct 31, 2016, at 8:05 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> 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
> >>
> >> _______________________________________________
> >> 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
