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

[Thorsten Seitz via swift-evolution]

+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 considerably (if it does, there's little reason to 
> replace optional binding), it's no less confusing than shadowing was when I 
> first saw it, and once you get used to it (shouldn't be more than a day): it 
> is less verbose and perhaps more intuitive (I've found myself reacting to 
> optionals saying "duh, I've already guarded that X is nonnull on this 
> codepath, why would I have to unwrap it again?" in Swift).
> 
>> On Tue, Jan 5, 2016 at 5:35 PM Dennis Lysenko  
>> wrote:
>> 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 uncomfortable seeing 
>> a variable change type in an inner scope" even though shadowing achieves 
>> exactly the same aim. The same happened the last time that type narrowing 
>> was mentioned.
>> 
>> 
>>> On Tue, Jan 5, 2016 at 5:27 PM Thorsten Seitz via swift-evolution 
>>>  wrote:
>>> Ceylon has type narrowing (not only for optional unwrapping but for type 
>>> checks as well): 
>>> http://ceylon-lang.org/documentation/1.2/tour/types/#narrowing_the_type_of_an_object_reference
>>> 
>>> It always struck me as quite natural to do this.
>>> 
>>> -Thorsten
>>> 
 Am 02.01.2016 um 06:08 schrieb Tyler Fleming Cloutier via swift-evolution 
 :
 
 
 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 to 
 Swift. This obviously doesn't help with the verbosity at all, but it seems 
 to be more consistent with ? being the operator for unwrapping.
 
 Of course there is also the current optional pattern matching syntax:
 
 if case let foo? = foo {
 
 }
 
 This accomplishes the same thing and is somewhat less perplexing than "if 
 let foo = foo", but must still be baffling to a new user.
 
 You could even have:
 
 if foo? {
 foo.blah()
 }
 
 Which would not create a shadow local variable but would have the same 
 semantics as
 
 foo?.blah()
 
 in that is just providing conditional access to the variable if it's not 
 .None. Not sure if this direct access is desired as it is still magical 
 scoped type manipulation without declaring a new variable.
 
 
 Tyler
 
 
> On Jan 1, 2016, at 11:44 PM, Tyler Cloutier  wrote:
> 
> 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 
>>  wrote:
>> 
>> 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 be:
>> 
>> if let foo? {
>>   // code that uses foo
>> }
>> 
>> What do you think?
>> 
>> – Cihat
>> 
 Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution 
 :
 
 
 On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via 
 swift-evolution  wrote:
 
 I was going to suggest something similar (a hard naming problem also):
 
 if has foo {
 // foo is now unwrapped and non-optional
 }
 
 guard has foo else { return }
 
 Does the same thing as `let foo = foo` in practice, but places it in a 
 somewhat different mental model. Instead of unwrapping and immediately 
 assigning to a new constant with the same name (which just looks kind 
 of silly, like some magic voodoo ritual), it sort of asserts that we 
 “have” foo (i.e. it’s not nil), and 

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

[Dennis Lysenko via swift-evolution]

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 uncomfortable
seeing a variable change type in an inner scope" even though shadowing
achieves exactly the same aim. The same happened the last time that type
narrowing was mentioned.


On Tue, Jan 5, 2016 at 5:27 PM Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> Ceylon has type narrowing (not only for optional unwrapping but for type
> checks as well):
> http://ceylon-lang.org/documentation/1.2/tour/types/#narrowing_the_type_of_an_object_reference
>
> It always struck me as quite natural to do this.
>
> -Thorsten
>
> Am 02.01.2016 um 06:08 schrieb Tyler Fleming Cloutier via swift-evolution <
> swift-evolution@swift.org>:
>
>
> 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 to
> Swift. This obviously doesn't help with the verbosity at all, but it seems
> to be more consistent with ? being the operator for unwrapping.
>
> Of course there is also the current optional pattern matching syntax:
>
> if case let foo? = foo {
>
> }
>
> This accomplishes the same thing and is somewhat less perplexing than "if
> let foo = foo", but must still be baffling to a new user.
>
> You could even have:
>
> if foo? {
> foo.blah()
> }
>
> Which would not create a shadow local variable but would have the same
> semantics as
>
> foo?.blah()
>
> in that is just providing conditional access to the variable if it's not
> .None. Not sure if this direct access is desired as it is still magical
> scoped type manipulation without declaring a new variable.
>
>
> Tyler
>
>
> On Jan 1, 2016, at 11:44 PM, Tyler Cloutier  wrote:
>
> 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 <
> swift-evolution@swift.org> wrote:
>
> 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 be:
>
> if let foo? {
>   // code that uses foo
> }
>
> What do you think?
>
> – Cihat
>
> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution <
> swift-evolution@swift.org>:
>
>
> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I was going to suggest something similar (a hard naming problem also):
>
> if has foo {
> // foo is now unwrapped and non-optional
> }
>
> guard has foo else { return }
>
> Does the same thing as `let foo = foo` in practice, but places it in a
> somewhat different mental model. Instead of unwrapping and immediately
> assigning to a new constant with the same name (which just looks kind of
> silly, like some magic voodoo ritual), it sort of asserts that we “have”
> foo (i.e. it’s not nil), and therefore from that point it can just be
> treated as non-optional.
>
> IMHO this, although introduces a new keyword, makes more sense than trying
> to reuse “let” in a context where it seems nonsensical. Perhaps this would
> be closer to Swift’s goals, by reducing very common boilerplate, but
> without harming clarity in a way adding a new meaning to “let” would.
>
> Curious to hear Chris Lattner’s opinion :-)
>
>
> IANACL (I am not a Chris Lattner) but, FWIW, several of us are
> uncomfortable with the idea that a single declared property might have
> different static types in different regions of code.
>
>
> — Radek
>
> On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 Wooten via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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 

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

[Tyler Fleming Cloutier via swift-evolution]

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 to Swift. 
This obviously doesn't help with the verbosity at all, but it seems to be more 
consistent with ? being the operator for unwrapping.

Of course there is also the current optional pattern matching syntax:

if case let foo? = foo {

}

This accomplishes the same thing and is somewhat less perplexing than "if let 
foo = foo", but must still be baffling to a new user.

You could even have:

if foo? {
foo.blah()
}

Which would not create a shadow local variable but would have the same 
semantics as

foo?.blah()

in that is just providing conditional access to the variable if it's not .None. 
Not sure if this direct access is desired as it is still magical scoped type 
manipulation without declaring a new variable.


Tyler


> On Jan 1, 2016, at 11:44 PM, Tyler Cloutier  wrote:
> 
> 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 
> > wrote:
> 
>> 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 be:
>> 
>> if let foo? {
>>   // code that uses foo
>> }
>> 
>> What do you think?
>> 
>> – Cihat
>> 
>>> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution 
>>> >:
>>> 
 
 On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution 
 > wrote:
 
 I was going to suggest something similar (a hard naming problem also):
 
 if has foo {
 // foo is now unwrapped and non-optional
 }
 
 guard has foo else { return }
 
 Does the same thing as `let foo = foo` in practice, but places it in a 
 somewhat different mental model. Instead of unwrapping and immediately 
 assigning to a new constant with the same name (which just looks kind of 
 silly, like some magic voodoo ritual), it sort of asserts that we “have” 
 foo (i.e. it’s not nil), and therefore from that point it can just be 
 treated as non-optional.
 
 IMHO this, although introduces a new keyword, makes more sense than trying 
 to reuse “let” in a context where it seems nonsensical. Perhaps this would 
 be closer to Swift’s goals, by reducing very common boilerplate, but 
 without harming clarity in a way adding a new meaning to “let” would.
 
 Curious to hear Chris Lattner’s opinion :-) 
>>> 
>>> IANACL (I am not a Chris Lattner) but, FWIW, several of us are 
>>> uncomfortable with the idea that a single declared property might have 
>>> different static types in different regions of code.
>>> 
 
 — Radek
 
> On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution 
> > wrote:
> 
> 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 Wooten via swift-evolution 
> > wrote:
> 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 necessary 
> information for this statement.
> 
> When it comes to newcomers I think you'd be hard pressed to find somebody 
> who'd be able to understand either form without teaching; so not losing 
> much there.
> 
> 
> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution 
> > wrote:
> 
>> 
>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
>>> > wrote:

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

[Tyler Cloutier via swift-evolution]

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 
>  wrote:
> 
> 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 be:
> 
> if let foo? {
>   // code that uses foo
> }
> 
> What do you think?
> 
> – Cihat
> 
>>> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution 
>>> :
>>> 
>>> 
>>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution 
>>>  wrote:
>>> 
>>> I was going to suggest something similar (a hard naming problem also):
>>> 
>>> if has foo {
>>> // foo is now unwrapped and non-optional
>>> }
>>> 
>>> guard has foo else { return }
>>> 
>>> Does the same thing as `let foo = foo` in practice, but places it in a 
>>> somewhat different mental model. Instead of unwrapping and immediately 
>>> assigning to a new constant with the same name (which just looks kind of 
>>> silly, like some magic voodoo ritual), it sort of asserts that we “have” 
>>> foo (i.e. it’s not nil), and therefore from that point it can just be 
>>> treated as non-optional.
>>> 
>>> IMHO this, although introduces a new keyword, makes more sense than trying 
>>> to reuse “let” in a context where it seems nonsensical. Perhaps this would 
>>> be closer to Swift’s goals, by reducing very common boilerplate, but 
>>> without harming clarity in a way adding a new meaning to “let” would.
>>> 
>>> Curious to hear Chris Lattner’s opinion :-) 
>> 
>> IANACL (I am not a Chris Lattner) but, FWIW, several of us are uncomfortable 
>> with the idea that a single declared property might have different static 
>> types in different regions of code.
>> 
>>> 
>>> — Radek
>>> 
 On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution 
  wrote:
 
 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 Wooten via swift-evolution 
>  wrote:
> 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 necessary 
> information for this statement.
> 
> When it comes to newcomers I think you'd be hard pressed to find somebody 
> who'd be able to understand either form without teaching; so not losing 
> much there.
> 
> 
>> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
>>>  wrote:
>>> 
>>> I’ve had similar ideas to this. Instead of ditching the if let syntax 
>>> altogether, another approach would be to use the existing name if no 
>>> new name is given, so that this code:
>>> 
>>> if let foo = foo { /* use foo */ }
>>> 
>>> could become this code:
>>> 
>>> if let foo { /* use foo */ }
>>> 
>>> In both cases, foo is non-optional inside the braces. If you gave it 
>>> another name with the if let syntax, that would work as it does today.
>> 
>> Hi Jeff,
>> 
>> This is commonly requested - the problem is that while it does help 
>> reduce boilerplate, it runs counter to the goal of improving clarity.
>> 
>> -Chris
>> 
>> 
>> ___
>> 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
>>> 

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

[Tino Heth via swift-evolution]

> 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 Optional, the second one isn't.

Tino
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kyle Carson via swift-evolution]

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
}

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

> 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 given the same name as the original optional 
> variable, creating a shadow variable. This approach leads to odd looking code 
> like this:
> 
> if let nearestX = nearestX { closest = nearestX }
> guard let layer = layer else { continue } 
> // use layer
> 
> At a glance, and to Swift newcomers, this code looks completely non-sensical. 
> It's also verbose for simply ensuring the variable is non-nil. 
> 
> The solution:
> Swift should generate unwrapped shadow variables after nil checking. The 
> compiler would treat the below code as if it had created an unwrapped shadow 
> variable.

Hi Daniel,

We discussed this extensively (and for a while this was plan of record to 
implement) but it has some pretty significant challenges.  The main problem is 
that it makes it extremely unclear and unpredictable what the type of a 
variable is.  One of the primary reasons we constrain type inference to a 
statement boundary to is to make it more clear what is going on.  You don’t 
have “spooky type action at a distance” like you do in some other languages 
with whole-function type inference.

Type confusion is particularly problematic here because the different cases you 
have depending on what T? is:

- With something like Int?, there are many operations that make sense on Int 
but not on Int?
- With something like [Int]?, there are operations (like map) that make sense 
on both types.
- Some operations are completely common between the two (e.g. “let x = v”).

Further, swift has an implicit promotion from T to T?, which can cause 
extremely confusing downstream errors if you’re not aware of what is going on.  
There are also implementation concerns as well.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Wooten via swift-evolution]

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 necessary 
information for this statement.

When it comes to newcomers I think you'd be hard pressed to find somebody who'd 
be able to understand either form without teaching; so not losing much there.


> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
>>  wrote:
>> 
>> I’ve had similar ideas to this. Instead of ditching the if let syntax 
>> altogether, another approach would be to use the existing name if no new 
>> name is given, so that this code:
>> 
>>  if let foo = foo { /* use foo */ }
>> 
>> could become this code:
>> 
>>  if let foo { /* use foo */ }
>> 
>> In both cases, foo is non-optional inside the braces. If you gave it another 
>> name with the if let syntax, that would work as it does today.
> 
> Hi Jeff,
> 
> This is commonly requested - the problem is that while it does help reduce 
> boilerplate, it runs counter to the goal of improving clarity.
> 
> -Chris
> 
> 
> ___
> 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

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

[Dennis Lysenko via swift-evolution]

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 Wooten via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 necessary
> information for this statement.
>
> When it comes to newcomers I think you'd be hard pressed to find somebody
> who'd be able to understand either form without teaching; so not losing
> much there.
>
>
> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’ve had similar ideas to this. Instead of ditching the if let syntax
> altogether, another approach would be to use the existing name if no new
> name is given, so that this code:
>
> if let foo = foo { /* use foo */ }
>
> could become this code:
>
> if let foo { /* use foo */ }
>
> In both cases, foo is non-optional inside the braces. If you gave it
> another name with the if let syntax, that would work as it does today.
>
>
> Hi Jeff,
>
> This is commonly requested - the problem is that while it does help reduce
> boilerplate, it runs counter to the goal of improving clarity.
>
> -Chris
>
> ___
> 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

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

[Dennis Lysenko via swift-evolution]

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 swift-evolution <
> swift-evolution@swift.org> 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.
>
> Therefore I'm -1 on any proposal that hides explicit name binding and/or
> increases shadowing, including let foo and unwrap foo.
>
>
> +1 to that.  IMO re-using the same name for the unwrapped version of an
> optional variable does not help readability, and I don't want to encourage
> it.  In a localized context like this, a short name is often better anyway
> as it declutters the code inside the block.
>
>
> On Sat, Dec 19, 2015 at 21:31 Kevin Wooten via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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 necessary
>> information for this statement.
>>
>> When it comes to newcomers I think you'd be hard pressed to find somebody
>> who'd be able to understand either form without teaching; so not losing
>> much there.
>>
>>
>> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I’ve had similar ideas to this. Instead of ditching the if let syntax
>> altogether, another approach would be to use the existing name if no new
>> name is given, so that this code:
>>
>> if let foo = foo { /* use foo */ }
>>
>> could become this code:
>>
>> if let foo { /* use foo */ }
>>
>> In both cases, foo is non-optional inside the braces. If you gave it
>> another name with the if let syntax, that would work as it does today.
>>
>>
>> Hi Jeff,
>>
>> This is commonly requested - the problem is that while it does help
>> reduce boilerplate, it runs counter to the goal of improving clarity.
>>
>> -Chris
>>
>> ___
>> 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
>
>
> -Dave
>
>
>
> ___
> 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

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

[ilya via swift-evolution]

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, including let foo and unwrap foo.

On Sat, Dec 19, 2015 at 21:31 Kevin Wooten via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 necessary
> information for this statement.
>
> When it comes to newcomers I think you'd be hard pressed to find somebody
> who'd be able to understand either form without teaching; so not losing
> much there.
>
>
> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’ve had similar ideas to this. Instead of ditching the if let syntax
> altogether, another approach would be to use the existing name if no new
> name is given, so that this code:
>
> if let foo = foo { /* use foo */ }
>
> could become this code:
>
> if let foo { /* use foo */ }
>
> In both cases, foo is non-optional inside the braces. If you gave it
> another name with the if let syntax, that would work as it does today.
>
>
> Hi Jeff,
>
> This is commonly requested - the problem is that while it does help reduce
> boilerplate, it runs counter to the goal of improving clarity.
>
> -Chris
>
> ___
> 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

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

[Dave Abrahams via swift-evolution]

> 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 
different names inside the block from outside.
> This helps avoid overhead of repeated getters and method calls. Using shorter 
> names is automatically less descriptive; otherwise, people would advocate 
> using abbreviations in property names, which is a stylistic and readability 
> faux pas.
> 
"More descriptive" ≠ "more readable".  When writing, we don't go into reams of 
detail about everything; we go into detail about the salient things.  We have 
pronouns for a reason, e.g. "when a person arriving at the refrigerator opens 
the door, she sees what's inside; then she decides whether she wants it."  
"She" is a short name used in a localized context as a stand-in for a 
more-descriptive phrase, "a person arriving at the refrigerator".  Repeating 
the more descriptive phrase would harm readability.

> 
> On Sat, Dec 19, 2015, 4:34 PM Dennis Lysenko  > wrote:
> 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 
> > wrote:
>> 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 original property. 
>> 
>> Therefore I'm -1 on any proposal that hides explicit name binding and/or 
>> increases shadowing, including let foo and unwrap foo. 
> 
> +1 to that.  IMO re-using the same name for the unwrapped version of an 
> optional variable does not help readability, and I don't want to encourage 
> it.  In a localized context like this, a short name is often better anyway as 
> it declutters the code inside the block.
> 
>> 
>> On Sat, Dec 19, 2015 at 21:31 Kevin Wooten via swift-evolution 
>> > wrote:
>> 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 necessary 
>> information for this statement.
>> 
>> When it comes to newcomers I think you'd be hard pressed to find somebody 
>> who'd be able to understand either form without teaching; so not losing much 
>> there.
>> 
>> 
>> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>>> 
 On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
 > wrote:
 
 I’ve had similar ideas to this. Instead of ditching the if let syntax 
 altogether, another approach would be to use the existing name if no new 
 name is given, so that this code:
 
if let foo = foo { /* use foo */ }
 
 could become this code:
 
if let foo { /* use foo */ }
 
 In both cases, foo is non-optional inside the braces. If you gave it 
 another name with the if let syntax, that would work as it does today.
>>> 
>>> Hi Jeff,
>>> 
>>> This is commonly requested - the problem is that while it does help reduce 
>>> boilerplate, it runs counter to the goal of improving clarity.
>>> 
>>> -Chris
>>> 
>>> 
>>> ___
>>> 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 
>> 
> -Dave
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> 

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

[Dave Abrahams via swift-evolution]

> 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 original property. 
> 
> Therefore I'm -1 on any proposal that hides explicit name binding and/or 
> increases shadowing, including let foo and unwrap foo. 

+1 to that.  IMO re-using the same name for the unwrapped version of an 
optional variable does not help readability, and I don't want to encourage it.  
In a localized context like this, a short name is often better anyway as it 
declutters the code inside the block.

> 
> On Sat, Dec 19, 2015 at 21:31 Kevin Wooten via swift-evolution 
> > wrote:
> 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 necessary 
> information for this statement.
> 
> When it comes to newcomers I think you'd be hard pressed to find somebody 
> who'd be able to understand either form without teaching; so not losing much 
> there.
> 
> 
> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution 
> > wrote:
> 
>> 
>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
>>> > wrote:
>>> 
>>> I’ve had similar ideas to this. Instead of ditching the if let syntax 
>>> altogether, another approach would be to use the existing name if no new 
>>> name is given, so that this code:
>>> 
>>> if let foo = foo { /* use foo */ }
>>> 
>>> could become this code:
>>> 
>>> if let foo { /* use foo */ }
>>> 
>>> In both cases, foo is non-optional inside the braces. If you gave it 
>>> another name with the if let syntax, that would work as it does today.
>> 
>> Hi Jeff,
>> 
>> This is commonly requested - the problem is that while it does help reduce 
>> boilerplate, it runs counter to the goal of improving clarity.
>> 
>> -Chris
>> 
>> 
>> ___
>> 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 
> 
-Dave



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Wooten via swift-evolution]

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

Creating a less descriptive short name in place of usually more descriptive 
name, which is already used throughout your code, is not “more explicit”.  
You’ve removed shadowing and instead created two separately name variables 
referring to the same value. You’ve created _more_ ambiguity, not less.

Also, for 1 line blocks of code, “vc” might be ok but blocks 20 lines long that 
contain other contrived names, just to remove shadowing, (e.g. “vc2”, using 
your example) is only going to make it worse.

> Therefore I'm -1 on any proposal that hides explicit name binding and/or 
> increases shadowing, including let foo and unwrap foo. 
> 
> On Sat, Dec 19, 2015 at 21:31 Kevin Wooten via swift-evolution 
> > wrote:
> 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 necessary 
> information for this statement.
> 
> When it comes to newcomers I think you'd be hard pressed to find somebody 
> who'd be able to understand either form without teaching; so not losing much 
> there.
> 
> 
> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution 
> > wrote:
> 
>> 
>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
>>> > wrote:
>>> 
>>> I’ve had similar ideas to this. Instead of ditching the if let syntax 
>>> altogether, another approach would be to use the existing name if no new 
>>> name is given, so that this code:
>>> 
>>> if let foo = foo { /* use foo */ }
>>> 
>>> could become this code:
>>> 
>>> if let foo { /* use foo */ }
>>> 
>>> In both cases, foo is non-optional inside the braces. If you gave it 
>>> another name with the if let syntax, that would work as it does today.
>> 
>> Hi Jeff,
>> 
>> This is commonly requested - the problem is that while it does help reduce 
>> boilerplate, it runs counter to the goal of improving clarity.
>> 
>> -Chris
>> 
>> 
>> ___
>> 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

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

[Cihat Gündüz via swift-evolution]

> 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 point; "if let foo = bar" makes sense in a way, but just "if let 
> foo" is a bit nonsensical to me when I take my mind outside of the narrow 
> swift mindset I tend to get into. This extends to decorating the foo with a 
> question mark or a bang, imo. 

Thank you for the feedback, Dennis. That post you quote is amongst the ones I 
read and it is even the reason I am suggesting these alternatives. Let me 
explain my thinking behind my suggestions a bit. I agree with Chris that `if 
let foo { /* code */ }` isn’t very readable mainly because there is no action 
done on the `foo` like a `= bar` or something else. But I also had the thought 
‚why do I need to type this twice, can’t this be optimized?‘ quite a few times 
when I used `if let foo = foo { /* code */ }` in practice.

So that’s why I thought there must be a way. First I started with something 
that contained the `=` sign also using the shorthand `x += 1` for `x = x + 1` 
as an inspiration. That lead to things like these:

if let foo = _ { /* code */ }
if let foo = ! { /* code */ }
if let foo ?= _ { /* code */ }
if foo ?= foo { /* code */ }
if let foo ?= { /* code */ }

But being honest to myself I thought all of those were even less readable then 
`if let foo { /* code */ }`. But once I dropped the `=` sign like in `if let 
foo! { /* code */ }` I started to like the idea and still found it readable.

I generally read let like a ‚define constant with name‘ and a ! like ‚force 
unwrap value‘ so I would read `let foo!` as ‚define constant with name and 
force unwrap value`. But I agree that ? may be more correct which I read as 
`try to unwrap value only continuing if unwrap succeeds` so `let foo?` would 
read as `define constant with name and try to unwrap only continuing if unwrap 
succeeds`.

So in conclusion to me `if let foo { }` isn’t readable but `if let foo? { }` 
is. That is only my opinion though.

> 
> On Sat, Dec 19, 2015 at 7:02 PM Cihat Gündüz  > wrote:
> 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 be:
> 
> if let foo? {
>   // code that uses foo
> }
> 
> What do you think?
> 
> – Cihat
> 
>> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution 
>> >:
>> 
>>> 
>>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution 
>>> > wrote:
>>> 
>>> I was going to suggest something similar (a hard naming problem also):
>>> 
>>> if has foo {
>>> // foo is now unwrapped and non-optional
>>> }
>>> 
>>> guard has foo else { return }
>>> 
>>> Does the same thing as `let foo = foo` in practice, but places it in a 
>>> somewhat different mental model. Instead of unwrapping and immediately 
>>> assigning to a new constant with the same name (which just looks kind of 
>>> silly, like some magic voodoo ritual), it sort of asserts that we “have” 
>>> foo (i.e. it’s not nil), and therefore from that point it can just be 
>>> treated as non-optional.
>>> 
>>> IMHO this, although introduces a new keyword, makes more sense than trying 
>>> to reuse “let” in a context where it seems nonsensical. Perhaps this would 
>>> be closer to Swift’s goals, by reducing very common boilerplate, but 
>>> without harming clarity in a way adding a new meaning to “let” would.
>>> 
>>> Curious to hear Chris Lattner’s opinion :-) 
>> 
>> IANACL (I am not a Chris Lattner) but, FWIW, several of us are uncomfortable 
>> with the idea that a single declared property might have different static 
>> types in different regions of code.
>> 
>>> 
>>> — Radek
>>> 
 On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution 
 > wrote:
 
 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 Wooten via swift-evolution 
 > wrote:
 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 = 

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

[Cihat Gündüz via swift-evolution]

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 be:

if let foo? {
  // code that uses foo
}

What do you think?

– Cihat

> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution 
> :
> 
>> 
>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution 
>> > wrote:
>> 
>> I was going to suggest something similar (a hard naming problem also):
>> 
>> if has foo {
>> // foo is now unwrapped and non-optional
>> }
>> 
>> guard has foo else { return }
>> 
>> Does the same thing as `let foo = foo` in practice, but places it in a 
>> somewhat different mental model. Instead of unwrapping and immediately 
>> assigning to a new constant with the same name (which just looks kind of 
>> silly, like some magic voodoo ritual), it sort of asserts that we “have” foo 
>> (i.e. it’s not nil), and therefore from that point it can just be treated as 
>> non-optional.
>> 
>> IMHO this, although introduces a new keyword, makes more sense than trying 
>> to reuse “let” in a context where it seems nonsensical. Perhaps this would 
>> be closer to Swift’s goals, by reducing very common boilerplate, but without 
>> harming clarity in a way adding a new meaning to “let” would.
>> 
>> Curious to hear Chris Lattner’s opinion :-) 
> 
> IANACL (I am not a Chris Lattner) but, FWIW, several of us are uncomfortable 
> with the idea that a single declared property might have different static 
> types in different regions of code.
> 
>> 
>> — Radek
>> 
>>> On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution 
>>> > wrote:
>>> 
>>> 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 Wooten via swift-evolution 
>>> > wrote:
>>> 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 necessary 
>>> information for this statement.
>>> 
>>> When it comes to newcomers I think you'd be hard pressed to find somebody 
>>> who'd be able to understand either form without teaching; so not losing 
>>> much there.
>>> 
>>> 
>>> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
 
> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
> > wrote:
> 
> I’ve had similar ideas to this. Instead of ditching the if let syntax 
> altogether, another approach would be to use the existing name if no new 
> name is given, so that this code:
> 
>   if let foo = foo { /* use foo */ }
> 
> could become this code:
> 
>   if let foo { /* use foo */ }
> 
> In both cases, foo is non-optional inside the braces. If you gave it 
> another name with the if let syntax, that would work as it does today.
 
 Hi Jeff,
 
 This is commonly requested - the problem is that while it does help reduce 
 boilerplate, it runs counter to the goal of improving clarity.
 
 -Chris
 
 
 ___
 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 
>> 

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

[Kevin Wooten via swift-evolution]

> 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 at runtime here". Evidenced by its 
> only other uses--try!, force-unwrapping, and implicitly unwrapped optionals.
> 
> 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 point; "if let foo = bar" makes sense in a way, but just "if let 
> foo" is a bit nonsensical to me when I take my mind outside of the narrow 
> swift mindset I tend to get into. This extends to decorating the foo with a 
> question mark or a bang, imo. 

But, “if let foo = foo {}” makes no sense to anybody but people familiar with 
swift already.  Dropping the redundancy really doesn’t harm much because you’ll 
first have to learn what “let” is doing; once you know what “let” is doing “if 
let foo {}” is fairly clear.

> 
> On Sat, Dec 19, 2015 at 7:02 PM Cihat Gündüz  > wrote:
> 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 be:
> 
> if let foo? {
>   // code that uses foo
> }
> 
> What do you think?
> 
> – Cihat
> 
>> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution 
>> >:
>> 
>>> 
>>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution 
>>> > wrote:
>>> 
>>> I was going to suggest something similar (a hard naming problem also):
>>> 
>>> if has foo {
>>> // foo is now unwrapped and non-optional
>>> }
>>> 
>>> guard has foo else { return }
>>> 
>>> Does the same thing as `let foo = foo` in practice, but places it in a 
>>> somewhat different mental model. Instead of unwrapping and immediately 
>>> assigning to a new constant with the same name (which just looks kind of 
>>> silly, like some magic voodoo ritual), it sort of asserts that we “have” 
>>> foo (i.e. it’s not nil), and therefore from that point it can just be 
>>> treated as non-optional.
>>> 
>>> IMHO this, although introduces a new keyword, makes more sense than trying 
>>> to reuse “let” in a context where it seems nonsensical. Perhaps this would 
>>> be closer to Swift’s goals, by reducing very common boilerplate, but 
>>> without harming clarity in a way adding a new meaning to “let” would.
>>> 
>>> Curious to hear Chris Lattner’s opinion :-) 
>> 
>> IANACL (I am not a Chris Lattner) but, FWIW, several of us are uncomfortable 
>> with the idea that a single declared property might have different static 
>> types in different regions of code.
>> 
>>> 
>>> — Radek
>>> 
 On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution 
 > wrote:
 
 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 Wooten via swift-evolution 
 > wrote:
 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 necessary 
 information for this statement.
 
 When it comes to newcomers I think you'd be hard pressed to find somebody 
 who'd be able to understand either form without teaching; so not losing 
 much there.
 
 
 On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution 
 > wrote:
 
> 
>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
>> > wrote:
>> 
>> I’ve had similar ideas to this. Instead of ditching the if let syntax 
>> altogether, another approach would be to use the existing name if no new 
>> name is given, so that this code:
>> 
>>  if let