Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

+1 Type narrowing would also fit nicely with union types (as demonstrated in Ceylon). -Thorsten > Am 05.01.2016 um 23:37 schrieb Dennis Lysenko : > > That said, I am in favor of automatic type narrowing. As long as it doesn't > complicate the compiler

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

Thorsten, Not that I disapprove (Kotlin does the same and it's great), the precedent seems to have already been set in people's minds that there won't be any kind of implicit type narrowing and I predict a fair few will respond with "You can already do that with optional binding, and I'm

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

Whoops, errant button tap. I've always thought that, if let foo = foo? { } makes more sense than if let foo = foo { } as the ? indicates that you are unwrapping the optional and then assigning it to the new variable. The current syntax must seem incomprehensible/redundant to those new

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

I've always thought that, if let foo = foo? { } makes more sense than if let foo = foo { } as the ? indicates that you are unwrapping the optional and then assigning it to the new variable > On Dec 19, 2015, at 7:02 PM, Cihat Gündüz via swift-evolution >

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

> let color : Color? = getFavoriteColor() > if color != nil { > // Color is no longer an Optional > } well, I'd just write if let color = getFavoriteColor() {… This even more as the other solutions hide that "color" isn't the original "color" anymore inside the braces: The first one was an

[swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

I've got another solution. It's simple and very "swift". The code "var != nil" can be used as a hint to the compiler that *var* is not an optional. Code example: let color : Color? = getFavoriteColor() if color != nil { // Color is no longer an Optional }

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

> On Dec 11, 2015, at 8:11 AM, Daniel Hooper via swift-evolution > wrote: > > A very common pattern in swift code is to "guard let" or "if let" optionals > - this works by creating a new non-optional variable to be used by future > code. Often, the new variable is

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

As much fun as it to example with foo, I would argue the opposite when you use some real world variable names: if let someInterestingViewConroller = someInterestingViewConroller { } vs If let someInterestingViewConroller { } We know what let does and it should be enough to impart the

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

What if we made the keyword "unwrap"? if unwrap someViewController { // now there is a shadowing nonoptional (unwrapped) variable of the same name only within this scope, boiling down to simple syntactic sugar for optional binding and it is fairly clear. } On Sat, Dec 19, 2015, 1:31 PM Kevin

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

Disagree. Short names are less descriptive and less readable. And saying "shadowing is bad" without any argument is just silly for a mailing list. On Sat, Dec 19, 2015, 3:57 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > On Dec 19, 2015, at 12:37 PM, ilya via

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

I prefer if let vc = someInterestingViewConroller { vc.doSomething() } - Explicit is better than implicit - shadowing is bad - now there's no ambiguity about how to change the original property. Therefore I'm -1 on any proposal that hides explicit name binding and/or increases shadowing,

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

> On Dec 19, 2015, at 1:41 PM, Dennis Lysenko > wrote: > > Shadowing is good in this case because it lets you capture constant values > for the exact scope in which you need them. > That is completely independent of shadowing. You do that even if you choose

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

> On Dec 19, 2015, at 12:37 PM, ilya via swift-evolution > wrote: > > I prefer > > if let vc = someInterestingViewConroller { > vc.doSomething() > } > > - Explicit is better than implicit > - shadowing is bad > - now there's no ambiguity about how to change the

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

> On Dec 19, 2015, at 1:37 PM, ilya wrote: > > I prefer > > if let vc = someInterestingViewConroller { > vc.doSomething() > } > > - Explicit is better than implicit > - shadowing is bad > - now there's no ambiguity about how to change the original property. >

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

> However, you may be interested in the last email Chris sent in this chain > with regards to shortening it to just "let foo": > > "This is commonly requested - the problem is that while it does help reduce > boilerplate, it runs counter to the goal of improving clarity." > > He's got a

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

I’ve only read the last couple of posts but has anybody already suggested using something like this: if let foo! { // code that uses foo } People already know that the ! is unwrapping a value and that let is defining a new constant. So why not combine those two? Alternatively it could also

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

> On Dec 19, 2015, at 5:12 PM, Dennis Lysenko via swift-evolution > wrote: > > Cihat, if either of the two you proposed I would prefer "let foo?" as the > bang (!), outside of logical negation, carries a meaning of "this is > dangerous and something could go wrong