Re: [swift-evolution] guard let x = x

On Mon, Nov 14, 2016 at 10:41 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > I believe that covers all the major points of this discussion. If so, I'm > going to table this until phase 2. I seem to recall another possibility that was brought up in this thread, which

Re: [swift-evolution] guard let x = x

> On Nov 14, 2016, at 12:24 AM, Jonathan Hull via swift-evolution > wrote: > > >> On Nov 11, 2016, at 2:48 PM, Chris Lattner > > wrote: >> >>> To summarize: >>> >>> 1. Swift needs to introduce a `Result` type. >>

Re: [swift-evolution] guard let x = x

> On Nov 11, 2016, at 2:48 PM, Chris Lattner wrote: > >> To summarize: >> >> 1. Swift needs to introduce a `Result` type. > > Yes, but this is almost certainly a Swift 5 thing. We need to settle the > following arguments: > > 1) Does Result include async capabilities

Re: [swift-evolution] guard let x = x

Am 2016-11-04 06:55, schrieb Thorsten Seitz: vars cannot be type narrowed as soon as concurrency comes into play. That's why Ceylon restricts type narrowing to immutables. Are you afraid that your variable gets changed under your feet and afterwards does not conform to the narrowed type any

Re: [swift-evolution] guard let x = x

vars cannot be type narrowed as soon as concurrency comes into play. That's why Ceylon restricts type narrowing to immutables. -Thorsten > Am 03.11.2016 um 09:52 schrieb Martin Waitz via swift-evolution > : > > Am 2016-11-03 09:17, schrieb Pyry Jahkola via

Re: [swift-evolution] guard let x = x

> On 3 Nov 2016, at 08:17, Pyry Jahkola wrote: > > As pleasing as it sounds*), the idea of type narrowing breaks down badly if: > > – the binding is implicit (without explicit extra syntax involved) and > – what is bound happens to be mutable. > > An example being: > >

Re: [swift-evolution] guard let x = x

Am 2016-11-03 09:17, schrieb Pyry Jahkola via swift-evolution: As pleasing as it sounds*), the idea of type narrowing breaks down badly if: – the binding is implicit (without explicit extra syntax involved) and – what is bound happens to be mutable. An example being: // VAR message: String?

Re: [swift-evolution] guard let x = x

> if x != nil { > // x is definitely not nil inside this block (implicitly > unwrapped) Pyry already mentioned the problem that arise when x is a variable (is "x = nil" forbidden inside the block?). Properties add complications as well (especially, but not only, computed ones),

Re: [swift-evolution] guard let x = x

As pleasing as it sounds*), the idea of type narrowing breaks down badly if: – the binding is implicit (without explicit extra syntax involved) and – what is bound happens to be mutable. An example being: // var message: String? if message != nil { // magic turns 'message' into a

Re: [swift-evolution] guard let x = x

> On Nov 2, 2016, at 2:02 PM, Matthew Johnson via swift-evolution > wrote: >> On Nov 2, 2016, at 3:47 PM, Sean Heber via swift-evolution >> > wrote: >> >> For what it’s worth, I concur. I think type

Re: [swift-evolution] guard let x = x

> On Nov 2, 2016, at 3:47 PM, Sean Heber via swift-evolution > wrote: > > For what it’s worth, I concur. I think type narrowing makes it feel more like > the language is actually doing some work *for* me rather than me having to > babysit the language with some new

Re: [swift-evolution] guard let x = x

For what it’s worth, I concur. I think type narrowing makes it feel more like the language is actually doing some work *for* me rather than me having to babysit the language with some new syntax or keyword. l8r Sean > On Nov 2, 2016, at 3:25 PM, Haravikk via swift-evolution >

Re: [swift-evolution] guard let x = x

I still think that type narrowing is the right way to handle this like so: if x != nil { // x is definitely not nil inside this block (implicitly unwrapped) } // x remains optional outside of it if (x != nil) || (x == y) { // if y's type

Re: [swift-evolution] guard let x = x

I think I agree with Tino, the use-case of “unwrap” for shadowing is not compelling enough to justify adding a keyword. Moreover, regarding the generalized enum associated-value extraction situation, the approach I described earlier is copacetic to both destructuring tuples and leaving them

Re: [swift-evolution] guard let x = x

Imho it would be better not to add "uwrap". Yes, it might be nicer in some situations, but it is also nice to have a simple (or at least less complicated) language. For me, the actual benefit is to low to justify a separate keyword which creates questions that don't exist with the current

Re: [swift-evolution] guard let x = x

> Am 01.11.2016 um 19:42 schrieb Erica Sadun via swift-evolution > : > > Here are a few varieties of how that call might look versus the proposed > update for normal pattern matching: > > if unwrap .string(myString) ~= json { ... } > if unwrap .contact(code, _) ~=

Re: [swift-evolution] guard let x = x

> Le 1 nov. 2016 à 14:42, Erica Sadun via swift-evolution > a écrit : > > With massive revisions. I've added Xiaodi Wu to author list. I've combined > all unwrapping together. I've added a much more sensible approach (plus a > bluesky one) for real world

Re: [swift-evolution] guard let x = x

Please ignore, the mail was sent in error. > On 02 Nov 2016, at 07:13, Rien via swift-evolution > wrote: > > If using “unwrap” in itself, then it should be statement that only unwraps, > hence the > > Regards, > Rien > > Site: http://balancingrock.nl > Blog:

Re: [swift-evolution] guard let x = x

If using “unwrap” in itself, then it should be statement that only unwraps, hence the Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 02 Nov 2016, at 02:47, Dany St-Amant via

Re: [swift-evolution] guard let x = x

Gonna put in my 2 cents re shadowing being a source of bugs: I use explicit self everywhere in my codebase and it pairs wonderfully with shadowing, making the detailed example moot. As far as Dany's message, I think that's the best way to go forward with an unwrap keyword--just make it work

Re: [swift-evolution] guard let x = x

> Le 31 oct. 2016 à 17:44, Erica Sadun via swift-evolution > a écrit : > > >> On Oct 31, 2016, at 1:51 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> An alternative that would seem to satisfy some objections is to have a >> distinct

Re: [swift-evolution] guard let x = x

I am a little worried about shadowing as well (isn’t that why we don’t allow ‘let x’… even though it seems a bit more obvious to me with that syntax that there is shadowing?) Have we considered doing exactly what people naively expect? That is, instead of creating a shadow constant/variable,

Re: [swift-evolution] guard let x = x

It seems that we settle on a relatively 'long' keyword 'unwrap',  Did we consider a ? prefix operator? As we use the ? postfix in order to safely unpack, we could as well introduce prefix ? guard ?foo, ?bar else { return } It is 'expressive', and makes me think 'do I have?'.  It is less

Re: [swift-evolution] guard let x = x

> a) guard let foobar = foobar else { … } > b) guard unwrap foobar else { … } I would argue for c) guard let reallyFoobar = foobar else { … } (or perhaps guard let foobar_ = foobar else { … } ) That way one can use both an optional foobar and non-optional "unwrapped value of foobar at the

Re: [swift-evolution] guard let x = x

I just realized something we can already do *now* (albeit with a lot of boilerplate) that looks really sleek at the point of use. For example: let json = JSON.number(4) if let n = json.number { // n is a Double here } guard let s = json.string else { return } Making this work is

Re: [swift-evolution] guard let x = x

> On Oct 31, 2016, at 7:37 PM, Joe Groff 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 ` ref> != nil` as a statement condition to also unwrap the referenced >

Re: [swift-evolution] guard let x = x

-1 on if unwrap myValue { ... } In my opinion, *shadowing names is an anti-pattern,* so making it easier isn't something we should encourage. Detailed examples, shall you wish, are below. Consider a developer who is suddenly able to change all employment relationships in the company. He's

Re: [swift-evolution] guard let x = x

Bikeshedding here—is there any way we can make it look like this for enums? if let str = unwrap json.string { // str is the value from the .string enum case } Essentially, the “unwrap” keyword would treat the last “path component” of what follows as an enum case, and extract the associated

Re: [swift-evolution] guard let x = x

With massive revisions. I've added Xiaodi Wu to author list. I've combined all unwrapping together. I've added a much more sensible approach (plus a bluesky one) for real world enumerations. Gist with live updates here: https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c

Re: [swift-evolution] guard let x = x

Hi, > 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. Of course, we could specify something like: „after checking that some Optional is not nil, it is treated as an implicitly unwrapped

Re: [swift-evolution] guard let x = x

Sorry I wrote that last email off a little too fast, my head was still stuck in legacy Swift land. by `if let a = a, b = b, c = c { ... }` I meant to say `if let a = a, let b = b, let c = c { ... }` And here: > something like `if given a, b, c, c { ... }` looks like it could be an accidental

Re: [swift-evolution] guard let x = x

In Rust lang, it uses .unwrap and b can be a non-nil variable. guard a.unwrap, b, c.unwrap else { } On Tuesday, November 1, 2016, Nicholas Maccharoli via swift-evolution < swift-evolution@swift.org> wrote: > I like the idea of drying up something like `guard let x = x, let y = y, > let z = z

Re: [swift-evolution] guard let x = x

> On 1 Nov 2016, at 01:37, Joe Groff via swift-evolution > 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 ` ref> != nil` as a statement condition to also

Re: [swift-evolution] guard let x = x

Agreed, a change like this would make sense :). Sent from my iPhone > On 1 Nov 2016, at 01:58, Joe Groff via swift-evolution > wrote: > > >> On Oct 31, 2016, at 6:46 PM, Xiaodi Wu wrote: >> >> On Mon, Oct 31, 2016 at 8:37 PM, Joe Groff via

Re: [swift-evolution] guard let x = x

Isn't this ambiguous in case x is Bool? (Optional)? Do you mean to force-unwrap the bool and use it as a condition, or should the x be unwrapped (in which case it can be false)? Not a common case likely, but it is nevertheless something to think of. > On Nov 1, 2016, at 6:52 AM, David Sweeris

Re: [swift-evolution] guard let x = x

Between all the talk about unwrap and nonnill and whatnot, I've kinda lost track of what we're actually talking about. I think it's still about not having to type variables twice in guard statements, right? Has anyone suggested guard x! else {...} // x means x! now yet? - Dave Sweeris

Re: [swift-evolution] guard let x = x

> On Nov 1, 2016, at 2:46 AM, Xiaodi Wu via swift-evolution > wrote: > > On Mon, Oct 31, 2016 at 8:37 PM, Joe Groff via swift-evolution > > wrote: > Sorry for piling onto the bikeshed. We do already have a

Re: [swift-evolution] guard let x = x

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 > wrote: > > Sorry for piling onto the

Re: [swift-evolution] guard let x = x

> On Oct 31, 2016, at 6:46 PM, Xiaodi Wu wrote: > > On Mon, Oct 31, 2016 at 8:37 PM, Joe Groff via swift-evolution > wrote: > Sorry for piling onto the bikeshed. We do already have a notation for testing > that an Optional isn't nil, `x !=

Re: [swift-evolution] guard let x = x

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 ` != nil` as a statement condition to also

Re: [swift-evolution] guard let x = x

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 ` != nil` as a statement condition to also unwrap the referenced declaration in the scope guarded by the condition. (` is T` could similarly rebind

Re: [swift-evolution] guard let x = x

One thing I really like that Erica mentioned in the earlier discussion is the case of guard unwrapping [weak self] in closures. I've taken to creating an alternate self (guard let ss = self else { return }) constant and using that. But it always felt inelegant. The proposed case works without

Re: [swift-evolution] guard let x = x

> On Oct 31, 2016, at 3:44 PM, Erica Sadun via swift-evolution > wrote: > > >> On Oct 31, 2016, at 1:51 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> An alternative that would seem to satisfy some objections is to have a >>

Re: [swift-evolution] guard let x = x

On Mon, Oct 31, 2016 at 4:44 PM, Erica Sadun wrote: > > > On Oct 31, 2016, at 1:51 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > > An alternative that would seem to satisfy some objections is to have a > distinct "unwrap" statement--as in:

Re: [swift-evolution] guard let x = x

> On Oct 31, 2016, at 1:51 PM, Xiaodi Wu via swift-evolution > wrote: > > An alternative that would seem to satisfy some objections is to have a > distinct "unwrap" statement--as in: "unwrap x else { ... }". I'd be against this alternative as it is doing the work

Re: [swift-evolution] guard let x = x

> On 31 Oct 2016, Xiaodi Wu wrote: > > Don't we currently have "for x in y" and "for var x in y"? So, we could have > "unwrap x" and "unwrap var x". > > And since unwrap wouldn't allow arbitrary Boolean expressions at the front > like if and guard statements do, it could use the where clause

Re: [swift-evolution] guard let x = x

Don't we currently have "for x in y" and "for var x in y"? So, we could have "unwrap x" and "unwrap var x". And since unwrap wouldn't allow arbitrary Boolean expressions at the front like if and guard statements do, it could use the where clause like for loops do. On Mon, Oct 31, 2016 at 14:58

Re: [swift-evolution] guard let x = x

> On 31 Oct 2016, Xiaodi Wu wrote: > > An alternative that would seem to satisfy some objections is to have a > distinct "unwrap" statement--as in: "unwrap x else { ... }". True. The `let`, on the other hand, has the minor upside that it's naturally substituted with `var` where in-place

Re: [swift-evolution] guard let x = x

It doesn't in a sense "it currently works like this", but it would be theoretically possible to have the compiler understand some static conditions, such as /// x is Int guard x > 0 else { return } if x == -1 { // Warning ... Then when you'd compare x == -1, you could get a warning

Re: [swift-evolution] guard let x = x

An alternative that would seem to satisfy some objections is to have a distinct "unwrap" statement--as in: "unwrap x else { ... }". On Mon, Oct 31, 2016 at 14:49 Pyry Jahkola via swift-evolution < swift-evolution@swift.org> wrote: > Going back to the originating message of this thread. This idea

Re: [swift-evolution] guard let x = x

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

Re: [swift-evolution] guard let x = x

Going back to the originating message of this thread. This idea (or a variant thereof) has been mentioned in the list of Commonly Rejected Proposals (2nd last bullet under Control Flow, Closures, Optional Binding, and Error Handling

Re: [swift-evolution] guard let x = x

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 > wrote: > > Well, "guard x != nil" does not unwrap

Re: [swift-evolution] guard let x = x

> On Oct 31, 2016, at 1:22 PM, William Sumner via swift-evolution > wrote: > > >> On Oct 31, 2016, at 1:11 PM, Kenny Leung via swift-evolution >> wrote: >> >> OK then, how about an extension to the proposal that says “guard variable

Re: [swift-evolution] guard let x = x

> On Oct 31, 2016, at 1:11 PM, Kenny Leung via swift-evolution > wrote: > > OK then, how about an extension to the proposal that says “guard variable > always implies guard unwrap variable when the only thing present in the guard > clause is an optional or list of

Re: [swift-evolution] guard let x = x

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

Re: [swift-evolution] guard let x = x

OK then, how about an extension to the proposal that says “guard variable always implies guard unwrap variable when the only thing present in the guard clause is an optional or list of optionals”? So you could write guard foo else { } guard foo, bar else { } -Kenny > On Oct 31, 2016, at

Re: [swift-evolution] guard let x = x

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

Re: [swift-evolution] guard let x = x

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 wrote: > Without going back through the history,

Re: [swift-evolution] guard let x = x

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 >

Re: [swift-evolution] guard let x = x

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? > >

Re: [swift-evolution] guard let x = x

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 wrote: > > Because there's an action taking place in addition to guarding >

Re: [swift-evolution] guard let x = x

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 > wrote: > > Why have the “unwrap” keyword at all? Isn’t “guard” the keyword? > > guard blah else { > } > > -Kenny > > >> On Oct

Re: [swift-evolution] guard let x = x

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 > wrote: > > >> On Oct 26, 2016, at 11:39 AM, Chris Lattner via swift-evolution >>

Re: [swift-evolution] guard let x = x

I hate keeping this going even though we decided to put it off for phase 2, but I just had to add something: Why not just put @unwrappable on the actual unwrappable case instead of the enum itself? You could even make multiple cases @unwrappable to specify (given that they have the same type)

Re: [swift-evolution] guard let x = x

> On 29 Oct 2016, at 02:10, Erica Sadun via swift-evolution > wrote: > > Sounds good to me. Leaving the gist in its updated state (a little further > from the last time) for the record. I like the first part, even though I disagree that `if let foo = foo` conflicts

Re: [swift-evolution] guard let x = x

I like the simplicity of 'unwrap' solving the issue of repetition, but it assumes 'let' in each example I've seen. 'guard var x = x' may not be written as frequently, but it is still valid. I can't imagine the intention would be that 'unwrap' is only for 'let' On Sun, Oct 30, 2016 at 5:18 AM

Re: [swift-evolution] guard let x = x

@unwrappable(type: Int) > public enum Count { > case none // not unwrappable > case many // not unwrappable > case some(Int) > case owed(Int) > case something(String) // not unwrappable > case multiple(Int, Int) // not unwrappable > } > > Instead of requiring the

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 10:37 AM, Chris Lattner via swift-evolution > wrote: > > To me, this is the most promising direction, but I’d suggest the use of > “unwrap" as the keyword. If you compare these two: > > a) guard let foobar = foobar else { … } > b) guard

Re: [swift-evolution] guard let x = x

+1 Can “unwrap” be used anywhere else? If not, why not remove the “guard” altogether? I.e. unwrap foobar else { … } Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 29 Oct 2016, at 00:34,

Re: [swift-evolution] guard let x = x

I think we should just have an “Unwrappable” protocol with a function/property that gets called by the statement. Then types can just define it for themselves based on whatever makes sense. That, or Xiaodi’s idea for union types (since I really want union types) Thanks, Jon > > On Oct 28,

Re: [swift-evolution] guard let x = x

Sounds good to me. Leaving the gist in its updated state (a little further from the last time) for the record. -- E > On Oct 28, 2016, at 7:02 PM, Xiaodi Wu wrote: > > Granted that this whole topic is out of scope currently, I think the enum > unwrapping facility is its

Re: [swift-evolution] guard let x = x

Granted that this whole topic is out of scope currently, I think the enum unwrapping facility is its own subject entirely, separable from the `if let x = x` sugar. Approaching this issue from another perspective--namely, improving enums to better enable some use cases prompted by requests for

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 6:22 PM, Erica Sadun via swift-evolution > wrote: >> On Oct 28, 2016, at 5:55 PM, Kevin Nattinger > > wrote: >>> On Oct 28, 2016, at 4:45 PM, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 16:45, Erica Sadun wrote: > > >> On Oct 28, 2016, at 5:00 PM, Huon Wilson > > wrote: >> >> >>> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] guard let x = x

> > On Oct 28, 2016, at 5:55 PM, Kevin Nattinger wrote: > >> >> On Oct 28, 2016, at 4:45 PM, Erica Sadun via swift-evolution >> > wrote: >> >> >>> On Oct 28, 2016, at 5:00 PM, Huon Wilson >>

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 4:45 PM, Erica Sadun via swift-evolution > wrote: > > >> On Oct 28, 2016, at 5:00 PM, Huon Wilson > > wrote: >> >> >>> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 5:00 PM, Huon Wilson wrote: > > >> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution >> > wrote: >> >>

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution > wrote: > > Detailed > Design > > unwrap can be used with any one-value enumeration. The unwrapped value is > bound to

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 11:39 AM, Chris Lattner via swift-evolution > wrote: > > >> On Oct 26, 2016, at 10:23 AM, Joshua Alvarado >> wrote: >> >> In your example the keyword only makes sense if you are shadowing the >> optional variable.

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 9:37 AM, Chris Lattner via swift-evolution > wrote: > To me, this is the most promising direction, but I’d suggest the use of > “unwrap" as the keyword. If you compare these two: > > a) guard let foobar = foobar else { … } > b) guard unwrap

Re: [swift-evolution] guard let x = x

First off, Chris made it clear dealing with this isn't a priority for Swift 4 so take my comments (inline below) with a grain of salt. At least for the time being this horse should Rest In Peace. > On Oct 26, 2016, at 11:58 AM, Erica Sadun wrote: > > >> On Oct 26,

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 10:23 AM, Joshua Alvarado > 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

Re: [swift-evolution] guard let x = x

In your example the keyword only makes sense if you are shadowing the optional variable. How would unwrap work with a different name? Ex: guard let bar = foo else {...} guard unwrap bar else {...} -> There is no context to what the guard is unwrapping This could end up leading to: guard unwrap

Re: [swift-evolution] guard let x = x

On Oct 26, 2016, at 9:37 AM, Chris Lattner via swift-evolution > wrote: To me, this is the most promising direction, but I’d suggest the use of “unwrap" as the keyword. If you compare these two: a) guard let foobar = foobar else { …

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 8:58 AM, Erica Sadun via swift-evolution > wrote: >> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution >> > wrote: >> >> Hey all, >> >> As usual, apologies if this horse

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution > wrote: > > Hey all, > > As usual, apologies if this horse was beaten ages ago before I joined the > mailing list, but thought I would bring this up. > > I was typing the above (for the hundredth

[swift-evolution] guard let x = x

Hey all, As usual, apologies if this horse was beaten ages ago before I joined the mailing list, but thought I would bring this up. I was typing the above (for the hundredth time) the other day and I was wondering whether it might be worth considering offering a shorter syntax: guard let x,