[swift-evolution] guard let x = x

Kenny Leung kenny_leung at pobox.com
Mon Oct 31 14:33:36 CDT 2016 

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 at 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 <charlie at 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 at 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 <alvaradojoshua0 at 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 at swift.org> wrote:
>> 
>>> Because "guard" already means something...
>>> 
>>> 
>>> On Mon, Oct 31, 2016 at 13:45 Kenny Leung via swift-evolution <swift-evolution at 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 <erica at 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 at 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 at swift.org> wrote:
>>> >>>
>>> >>>
>>> >>>> On Oct 26, 2016, at 11:39 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>> >>>>
>>> >>>>
>>> >>>>> On Oct 26, 2016, at 10:23 AM, Joshua Alvarado <alvaradojoshua0 at 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 at swift.org
>>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> >>
>>> >> _______________________________________________
>>> >> swift-evolution mailing list
>>> >> swift-evolution at swift.org
>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> >
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list