Proposal Sketch: simplify optional unwrapping syntax

[Radek_Pietruszewski]

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

— 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 <mailto: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 <mailto:swift-evolution@swift.org>> wrote:

On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

[dabrahams (Dave Abrahams)]

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

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

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.

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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

···

On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Sat, Dec 19, 2015, 1:31 PM Kevin Wooten via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

[Dennis_Lysenko]

Shadowing is good in this case because it lets you capture constant values
for the exact scope in which you need them. 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.

···

On Sat, Dec 19, 2015, 4:34 PM Dennis Lysenko <dennis.s.lysenko@gmail.com> 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 < > 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

[Cihat_Gunduz (Cihat Gündüz)]

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

On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[dabrahams (Dave Abrahams)]

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.

Disagree. Short names are less descriptive and less readable. And saying "shadowing is bad" without any argument is just silly for a mailing list.

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.

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.

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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

···

On Dec 19, 2015, at 1:41 PM, Dennis Lysenko <dennis.s.lysenko@gmail.com> wrote:
On Sat, Dec 19, 2015, 4:34 PM Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:
On Sat, Dec 19, 2015, 3:57 PM Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 19, 2015, at 12:37 PM, ilya via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Sat, Dec 19, 2015 at 21:31 Kevin Wooten via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

[Kevin_Wooten]

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 Dec 19, 2015, at 5:12 PM, Dennis Lysenko via swift-evolution <swift-evolution@swift.org> wrote:

On Sat, Dec 19, 2015 at 7:02 PM Cihat Gündüz <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>>:

On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>> wrote:

On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Dennis_Lysenko]

Another argument is in a large block with several bound optionals, reusing
names prevents people from accidentally accessing optionals that were
already bound to non optional values.

We were all skeptical, I think, of reusing names in optional binding at
first (I thought it looked ugly), but I grew accustomed to it and it works
really well. Even Ray Wenderlich's style guide (only comprehensive one I've
come across so far) suggests doing that. May I ask if those who oppose
shadowing in optional binding have ever actually given it a chance?

···

On Sat, Dec 19, 2015, 4:41 PM Dennis Lysenko via swift-evolution < swift-evolution@swift.org> wrote:

Shadowing is good in this case because it lets you capture constant values
for the exact scope in which you need them. 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.

On Sat, Dec 19, 2015, 4:34 PM Dennis Lysenko <dennis.s.lysenko@gmail.com> > 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 < >> 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

[Dennis_Lysenko]

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.

···

On Sat, Dec 19, 2015 at 7:02 PM Cihat Gündüz <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 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

_______________________________________________
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

[Cihat_Gunduz (Cihat Gündüz)]

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 <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>>:

On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>> wrote:

On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Tino]

One question first: Have you thought of user trying to do
let object.someProperty
?
The syntax looks like a nice shortcut at the first glance, but we shouldn't forget that there is already a different shortcut involved in many of those assignments:
self.foo...

But, “if let foo = foo {}” makes no sense to anybody but people familiar with swift already.

I've to agree on that — imho the syntax isn't very intuitive.
But it has the advantage to make clear that you declare a new value with the name "foo" (without explaining why that new foo has a different type despite using the normal assignment operator… I wonder if there has been a discussion about something like "?=")

For me everything boils down that we as programmers put a lot of stress on those tiny equal signs (to bad our natural language evolved in the way it did ;-), but that's life, and we know how to deal with it.

[cloutiertyler (Tyler Cloutier)]

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

_______________________________________________
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

[Dennis_Lysenko]

@Kevin: That is why I'm suggesting if unwrap foo {, because I believe it's
clearer than either. I was trying to say, though, that "if let foo = bar",
one of the first things you learn in swift, transitions naturally to "if
let foo = foo", though slightly disorienting at first, but will be
disconnected from just "if let foo" due to being in a fundamentally
different format.

@Cihat: Aha, interesting points. I still think a more explicit keyword like
"unwrap" or "bind" would achieve a bit more clarity.

···

On Sat, Dec 19, 2015 at 7:47 PM Cihat Gündüz <CihatGuenduez@posteo.de> wrote:

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

_______________________________________________
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

[cloutiertyler (Tyler Cloutier)]

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 <cloutiertyler@aol.com> 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 <mailto: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 <mailto:swift-evolution@swift.org>>:

On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>> wrote:

On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[trs (Thorsten Seitz)]

Ceylon has type narrowing (not only for optional unwrapping but for type checks as well): Eclipse Ceylon™ | projects.eclipse.org

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 <cloutiertyler@aol.com <mailto:cloutiertyler@aol.com>> 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 <mailto: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 <mailto:swift-evolution@swift.org>>:

On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>> wrote:

On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Dennis_Lysenko]

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):
Eclipse Ceylon™ | projects.eclipse.org

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 <cloutiertyler@aol.com> 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 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

_______________________________________________
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

_______________________________________________
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

[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 <dennis.s.lysenko@gmail.com> 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 < > swift-evolution@swift.org> wrote:

Ceylon has type narrowing (not only for optional unwrapping but for type
checks as well):
Eclipse Ceylon™ | projects.eclipse.org

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 <cloutiertyler@aol.com> >> 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 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

_______________________________________________
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

_______________________________________________
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

[trs (Thorsten Seitz)]

+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 <dennis.s.lysenko@gmail.com>:

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 <dennis.s.lysenko@gmail.com> 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 <swift-evolution@swift.org> wrote:
Ceylon has type narrowing (not only for optional unwrapping but for type checks as well): Eclipse Ceylon™ | projects.eclipse.org

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 <cloutiertyler@aol.com> 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 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

_______________________________________________
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

_______________________________________________
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

[James_Campbell]

We should add an unless one to compliement it :)

unless foo?
{
}

···

On Wed, Jan 6, 2016 at 6:16 AM, Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote:

+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 <dennis.s.lysenko@gmail.com > >:

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 <dennis.s.lysenko@gmail.com> > 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 < >> swift-evolution@swift.org> wrote:

Ceylon has type narrowing (not only for optional unwrapping but for type
checks as well):
Eclipse Ceylon™ | projects.eclipse.org

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 <cloutiertyler@aol.com> >>> 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 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

_______________________________________________
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

_______________________________________________
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

--
 Wizard
james@supmenow.com
+44 7523 279 698