[Idea] "guard not let" optional binding

Karl · 2016-05-14T05:52:17.000Z

If we want to check that an optional has a value and bail if it doesn't, we have the helpful pattern:

guard let x = x else { throw SomeError }

However, it is also fairly common that you want to check that an optional *is* nil, and still bail if it isn’t (maybe using the value that you now know exists), e.g:

guard cachedValue == nil else { return cachedValue! }
cachedValue = //… expensive calculation

It seems a little bit “unfair” that we have this lovely clean `let` syntax when checking for Optional.Some, but we to have to do this ugly manual check against nil and explicit unwrap when checking for Optional.None. There is literally no other way to satisfy the guard statement; our optional bindings only go one-way can’t be evaluated.

What about if we introduced a “not” modifier to optional bindings?

guard not let cachedValue = _someExpensiveResult else { return cachedValue }

This obviously wouldn’t make sense for “if let…” switching, as the variables get bound in the ‘else’ block and the code wouldn’t be very readable. For the special case of a guard statement, though, which only has an ‘else’ block, it does make some sense.

If we had something like this, certainly in my code, I’d be able to eliminate almost all (maybe even all) remaining force-unwraps of optionals; that’s great! It’d be amazing if the language was expressive enough that you could go without ever having to force-unwrap an optional. And it just makes sense.

Thoughts?

Karl

VladimirS · 2016-05-14T07:20:57.000Z

-1 as there IMO some confusion between all these `not` and `else` and the meaning of the expression at all is not obvious for me: "check that not allowed to assign _someExpensiveResult to some instance cachedValue, otherwise return something"

This really looks nice, clean and obvious :

guard cachedValue == nil else {
  // here you need just to fast return unwrapped value of cachedValue
  // so, IMO unwrapping it in this block is OK
  return cachedValue!
}
// here you want to have cachedValue == nil, so you'll need to unwrap it(after assignment) in any case.

What I can see as improvement in this direction, something like this:
guard cachedValue == nil else let cachedValue! {
// here you can use unwrapped cachedValue
return cachedValue
}

Hmm... Btw, what about improving in optional binding: It is common to shadow optional value name with unwrapped value with same name:

if let value = value {...} // too much noise

What about introduce such syntax:

if let value! {
// unwrapped value here
}

Seems like clear and obvious about what does this mean. Opinions? (before I drop this to separate thread)

···

On 14.05.2016 8:52, Karl via swift-evolution wrote:

If we want to check that an optional has a value and bail if it doesn't, we have the helpful pattern:

    guard let x = x else { throw SomeError }

However, it is also fairly common that you want to check that an optional *is* nil, and still bail if it isn’t (maybe using the value that you now know exists), e.g:

    guard cachedValue == nil else { return cachedValue! }
    cachedValue = //… expensive calculation

It seems a little bit “unfair” that we have this lovely clean `let` syntax when checking for Optional.Some, but we to have to do this ugly manual check against nil and explicit unwrap when checking for Optional.None. There is literally no other way to satisfy the guard statement; our optional bindings only go one-way can’t be evaluated.

What about if we introduced a “not” modifier to optional bindings?

    guard not let cachedValue = _someExpensiveResult else { return cachedValue }

This obviously wouldn’t make sense for “if let…” switching, as the variables get bound in the ‘else’ block and the code wouldn’t be very readable. For the special case of a guard statement, though, which only has an ‘else’ block, it does make some sense.

If we had something like this, certainly in my code, I’d be able to eliminate almost all (maybe even all) remaining force-unwraps of optionals; that’s great! It’d be amazing if the language was expressive enough that you could go without ever having to force-unwrap an optional. And it just makes sense.

Thoughts?

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

Patrick_Smith · 2016-05-14T05:56:12.000Z

I’d probably write that as:

if let value = cachedValue { return value }

cachedValue = // … expensive calculation

···

On 14 May 2016, at 3:52 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

If we want to check that an optional has a value and bail if it doesn't, we have the helpful pattern:

   guard let x = x else { throw SomeError }

However, it is also fairly common that you want to check that an optional *is* nil, and still bail if it isn’t (maybe using the value that you now know exists), e.g:

   guard cachedValue == nil else { return cachedValue! }
   cachedValue = //… expensive calculation

It seems a little bit “unfair” that we have this lovely clean `let` syntax when checking for Optional.Some, but we to have to do this ugly manual check against nil and explicit unwrap when checking for Optional.None. There is literally no other way to satisfy the guard statement; our optional bindings only go one-way can’t be evaluated.

What about if we introduced a “not” modifier to optional bindings?

   guard not let cachedValue = _someExpensiveResult else { return cachedValue }

This obviously wouldn’t make sense for “if let…” switching, as the variables get bound in the ‘else’ block and the code wouldn’t be very readable. For the special case of a guard statement, though, which only has an ‘else’ block, it does make some sense.

If we had something like this, certainly in my code, I’d be able to eliminate almost all (maybe even all) remaining force-unwraps of optionals; that’s great! It’d be amazing if the language was expressive enough that you could go without ever having to force-unwrap an optional. And it just makes sense.

Thoughts?

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

Karl · 2016-05-14T06:58:54.000Z

You could do that with everything and never use the guard statement at all if you wanted.

But it's actually pretty useful. There have been times where I’ve been heavily editing code and forgotten to leave the scope after a guard condition failed. Just recently I was editing some async functions with a callback with a throwable argument, I called the callback with the error but forgot to return afterwards; guard caught it for me.

Lets say I had your code, but was editing it to make it asynchronous:

if let value = cachedValue { return value }

cachedValue = // … expensive calculation
return cachedValue!

could become (if I was tired, in the middle of some big code changes):

if let value = cachedValue { callback(value) } // Oops, forgot to return, redundant re-calculation (and unexpected second callback) follows

cachedValue = // … expensive calculation
callback(cachedValue!)

guard wouldn’t let that happen. I use it every time I intend to exit scope early; it’s a better semantic model of my intention, so the compiler will notice on the off-chance I do mess up.

···

On 14 May 2016, at 07:56, Patrick Smith <pgwsmith@gmail.com> wrote:

I’d probably write that as:

if let value = cachedValue { return value }

cachedValue = // … expensive calculation

On 14 May 2016, at 3:52 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

If we want to check that an optional has a value and bail if it doesn't, we have the helpful pattern:

  guard let x = x else { throw SomeError }

However, it is also fairly common that you want to check that an optional *is* nil, and still bail if it isn’t (maybe using the value that you now know exists), e.g:

  guard cachedValue == nil else { return cachedValue! }
  cachedValue = //… expensive calculation

It seems a little bit “unfair” that we have this lovely clean `let` syntax when checking for Optional.Some, but we to have to do this ugly manual check against nil and explicit unwrap when checking for Optional.None. There is literally no other way to satisfy the guard statement; our optional bindings only go one-way can’t be evaluated.

What about if we introduced a “not” modifier to optional bindings?

  guard not let cachedValue = _someExpensiveResult else { return cachedValue }

This obviously wouldn’t make sense for “if let…” switching, as the variables get bound in the ‘else’ block and the code wouldn’t be very readable. For the special case of a guard statement, though, which only has an ‘else’ block, it does make some sense.

If we had something like this, certainly in my code, I’d be able to eliminate almost all (maybe even all) remaining force-unwraps of optionals; that’s great! It’d be amazing if the language was expressive enough that you could go without ever having to force-unwrap an optional. And it just makes sense.

Thoughts?

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

VladimirS · 2016-05-17T13:43:50.000Z

It is common to shadow optional value name with unwrapped value with same name:

if let someGoodValue = someGoodValue {...}

What if we'll have a syntax to not repeat the variable name to achieve the same target:

if let someGoodValue! {...}

What do you think?

johankj · 2016-05-17T13:51:31.000Z

This was one of the first and most commonly suggested ideas, when the Swift
Evolution mailing list first started.
Chris Lattner sums it up
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
in one of those threads:

This is commonly requested - the problem is that while it does help

reduce boilerplate, it runs counter to the goal of improving clarity.

— Johan

···

On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:

It is common to shadow optional value name with unwrapped value with same
name:

if let someGoodValue = someGoodValue {...}

What if we'll have a syntax to not repeat the variable name to achieve the
same target:

if let someGoodValue! {...}

What do you think?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

VladimirS · 2016-05-17T15:05:09.000Z

This was one of the first and most commonly suggested ideas, when the Swift

> Evolution mailing list first started.
> Chris Lattner sums it up
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan

Oh, thank you for letting this know.

Well, I totally disagree with Chris. And as soon as there was no 'official' proposal and 'official' decision, I'd like to discuss this more.

I saw a lot of code like
if let mySomeValue = mySomeValue {} in sources and even in books.
Plus, I really believe that
if let mySomeValue! {..} is better in any way: readability, less space for errors(when you need to repeat the same name) etc

FWIW, I suggest more explicit variant:
if let value! {...} // with exclamation mark
In that "old" proposal there was `if let value {...}`, was not so clear.

I can't accept an argument that you can use another name - as usually 'good' name is already 'crafted' for the instance and you want to use it in next code.
Otherwise, we need a 'best practice' to name optional variables with some prefix or suffix like : mySomeValueOpt, then `if let mySomeValue = mySomeValueOpt` will have a sense. But as I understand, we don't want to use such approach.
Additionally, when you shadow optional value with same name - you are *protecting* yourself from using optional value inside block of unwrapped code. IMO it is a good idea.
And want we or don't want, we already have this practice widely. So I believe this(my) proposal will improve the code.

I'd like to get opinion of the community regarding this feature.

···

On 17.05.2016 16:51, Johan Jensen wrote:

This was one of the first and most commonly suggested ideas, when the Swift
Evolution mailing list first started.
Chris Lattner sums it up
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
in one of those threads:

This is commonly requested - the problem is that while it does help

reduce boilerplate, it runs counter to the goal of improving clarity.

— Johan

On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    It is common to shadow optional value name with unwrapped value with
    same name:

    if let someGoodValue = someGoodValue {...}

    What if we'll have a syntax to not repeat the variable name to achieve
    the same target:

    if let someGoodValue! {...}

    What do you think?
    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

Daniel_Hopfl · 2016-05-18T08:21:12.000Z

Just an idea: Why don’t we think about it similar to try?

var anOptional : String?

let? anOptional { /* use it, but cannot change it */ }
let! anOptional { /* use it, without checking, cannot change it */ }

var? anOptional { /* use it, can also change it, */ }
var! anOptional { /* use it, without checking, can also change it */ }

Is it allowed to set it to nil in the var case? Hard to say.

···

On 17.05.16 15:43, Vladimir.S via swift-evolution wrote:

It is common to shadow optional value name with unwrapped value with
same name:

if let someGoodValue = someGoodValue {...}

What if we'll have a syntax to not repeat the variable name to achieve
the same target:

if let someGoodValue! {...}

What do you think?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

BigZaphod · 2016-05-17T15:15:41.000Z

Yep - same here. I think I was one of the first to propose we find some solution to this on the list back when it first started, and oddly enough, with more Swift experience comes less and less feeling of this even being a problem. I think as you start thinking more “in Swift” you start structuring your code differently, using guards, changing the nature of the flow, and suddenly these situations come up less often.

l8r
Sean

···

On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

While I've sometimes (early on) wished for a shorter-hand syntax for that construct, I've never been able to think of something that I thought was better. I've gotten to the point where I don't particularly mind it anymore.

Regarding the exclamation point specifically, seeing one of those in an expression context says to me "this thing will die horribly if it is nil/throws an error". Using it in this context where that's not the case would probably go against users' expectations.

On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when the Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
>
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan

Oh, thank you for letting this know.

Well, I totally disagree with Chris. And as soon as there was no 'official'
proposal and 'official' decision, I'd like to discuss this more.

I saw a lot of code like
if let mySomeValue = mySomeValue {} in sources and even in books.
Plus, I really believe that
if let mySomeValue! {..} is better in any way: readability, less space for
errors(when you need to repeat the same name) etc

FWIW, I suggest more explicit variant:
if let value! {...} // with exclamation mark
In that "old" proposal there was `if let value {...}`, was not so clear.

I can't accept an argument that you can use another name - as usually
'good' name is already 'crafted' for the instance and you want to use it in
next code.
Otherwise, we need a 'best practice' to name optional variables with some
prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
mySomeValueOpt` will have a sense. But as I understand, we don't want to
use such approach.
Additionally, when you shadow optional value with same name - you are
*protecting* yourself from using optional value inside block of unwrapped
code. IMO it is a good idea.
And want we or don't want, we already have this practice widely. So I
believe this(my) proposal will improve the code.

I'd like to get opinion of the community regarding this feature.

On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when the Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan
>
> On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> It is common to shadow optional value name with unwrapped value with
> same name:
>
> if let someGoodValue = someGoodValue {...}
>
> What if we'll have a syntax to not repeat the variable name to achieve
> the same target:
>
> if let someGoodValue! {...}
>
> What do you think?
> _______________________________________________
> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

anandabits · 2016-05-17T15:18:53.000Z

While I've sometimes (early on) wished for a shorter-hand syntax for that construct, I've never been able to think of something that I thought was better. I've gotten to the point where I don't particularly mind it anymore.

Regarding the exclamation point specifically, seeing one of those in an expression context says to me "this thing will die horribly if it is nil/throws an error". Using it in this context where that's not the case would probably go against users' expectations.

Agree. If we are going have syntax similar to pattern matching it should be the same as pattern matching. This would mean using ‘?' rather than ‘!’. However, we already have generalized pattern matching with `if case` for that. This topic has been debated extensively.

···

On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when the Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
>
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan

Oh, thank you for letting this know.

Well, I totally disagree with Chris. And as soon as there was no 'official'
proposal and 'official' decision, I'd like to discuss this more.

I saw a lot of code like
if let mySomeValue = mySomeValue {} in sources and even in books.
Plus, I really believe that
if let mySomeValue! {..} is better in any way: readability, less space for
errors(when you need to repeat the same name) etc

FWIW, I suggest more explicit variant:
if let value! {...} // with exclamation mark
In that "old" proposal there was `if let value {...}`, was not so clear.

I can't accept an argument that you can use another name - as usually
'good' name is already 'crafted' for the instance and you want to use it in
next code.
Otherwise, we need a 'best practice' to name optional variables with some
prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
mySomeValueOpt` will have a sense. But as I understand, we don't want to
use such approach.
Additionally, when you shadow optional value with same name - you are
*protecting* yourself from using optional value inside block of unwrapped
code. IMO it is a good idea.
And want we or don't want, we already have this practice widely. So I
believe this(my) proposal will improve the code.

I'd like to get opinion of the community regarding this feature.

On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when the Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan
>
> On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:
>
> It is common to shadow optional value name with unwrapped value with
> same name:
>
> if let someGoodValue = someGoodValue {...}
>
> What if we'll have a syntax to not repeat the variable name to achieve
> the same target:
>
> if let someGoodValue! {...}
>
> What do you think?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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

Tony_Allevato · 2016-05-17T15:13:02.000Z

While I've sometimes (early on) wished for a shorter-hand syntax for that
construct, I've never been able to think of something that I thought was
better. I've gotten to the point where I don't particularly mind it anymore.

Regarding the exclamation point specifically, seeing one of those in an
expression context says to me "this thing will die horribly if it is
nil/throws an error". Using it in this context where that's not the case
would probably go against users' expectations.

···

On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:

On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when the
Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
>
<
[swift-evolution] Proposal Sketch: simplify optional unwrapping syntax
>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan

Oh, thank you for letting this know.

Well, I totally disagree with Chris. And as soon as there was no 'official'
proposal and 'official' decision, I'd like to discuss this more.

I saw a lot of code like
if let mySomeValue = mySomeValue {} in sources and even in books.
Plus, I really believe that
if let mySomeValue! {..} is better in any way: readability, less space for
errors(when you need to repeat the same name) etc

FWIW, I suggest more explicit variant:
if let value! {...} // with exclamation mark
In that "old" proposal there was `if let value {...}`, was not so clear.

I can't accept an argument that you can use another name - as usually
'good' name is already 'crafted' for the instance and you want to use it in
next code.
Otherwise, we need a 'best practice' to name optional variables with some
prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
mySomeValueOpt` will have a sense. But as I understand, we don't want to
use such approach.
Additionally, when you shadow optional value with same name - you are
*protecting* yourself from using optional value inside block of unwrapped
code. IMO it is a good idea.
And want we or don't want, we already have this practice widely. So I
believe this(my) proposal will improve the code.

I'd like to get opinion of the community regarding this feature.

On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when the
Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
> <
[swift-evolution] Proposal Sketch: simplify optional unwrapping syntax
>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan
>
> On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> It is common to shadow optional value name with unwrapped value with
> same name:
>
> if let someGoodValue = someGoodValue {...}
>
> What if we'll have a syntax to not repeat the variable name to
achieve
> the same target:
>
> if let someGoodValue! {...}
>
> What do you think?
> _______________________________________________
> 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

L_Mihalkovic · 2016-05-17T15:36:30.000Z

FWIW, agreed that more complex guard statements with shorter methods avoid the issue altogether (reminds me of using unless for similar purpose in perl).

Regards
LM
(From mobile)

···

On May 17, 2016, at 5:15 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

Yep - same here. I think I was one of the first to propose we find some solution to this on the list back when it first started, and oddly enough, with more Swift experience comes less and less feeling of this even being a problem. I think as you start thinking more “in Swift” you start structuring your code differently, using guards, changing the nature of the flow, and suddenly these situations come up less often.

l8r
Sean

On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

While I've sometimes (early on) wished for a shorter-hand syntax for that construct, I've never been able to think of something that I thought was better. I've gotten to the point where I don't particularly mind it anymore.

Regarding the exclamation point specifically, seeing one of those in an expression context says to me "this thing will die horribly if it is nil/throws an error". Using it in this context where that's not the case would probably go against users' expectations.

On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

On 17.05.2016 16:51, Johan Jensen wrote:
This was one of the first and most commonly suggested ideas, when the Swift
Evolution mailing list first started.
Chris Lattner sums it up

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>

in one of those threads:

This is commonly requested - the problem is that while it does help

reduce boilerplate, it runs counter to the goal of improving clarity.

— Johan

Oh, thank you for letting this know.

Well, I totally disagree with Chris. And as soon as there was no 'official'
proposal and 'official' decision, I'd like to discuss this more.

I saw a lot of code like
if let mySomeValue = mySomeValue {} in sources and even in books.
Plus, I really believe that
if let mySomeValue! {..} is better in any way: readability, less space for
errors(when you need to repeat the same name) etc

FWIW, I suggest more explicit variant:
if let value! {...} // with exclamation mark
In that "old" proposal there was `if let value {...}`, was not so clear.

I can't accept an argument that you can use another name - as usually
'good' name is already 'crafted' for the instance and you want to use it in
next code.
Otherwise, we need a 'best practice' to name optional variables with some
prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
mySomeValueOpt` will have a sense. But as I understand, we don't want to
use such approach.
Additionally, when you shadow optional value with same name - you are
*protecting* yourself from using optional value inside block of unwrapped
code. IMO it is a good idea.
And want we or don't want, we already have this practice widely. So I
believe this(my) proposal will improve the code.

I'd like to get opinion of the community regarding this feature.

On 17.05.2016 16:51, Johan Jensen wrote:
This was one of the first and most commonly suggested ideas, when the Swift
Evolution mailing list first started.
Chris Lattner sums it up
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
in one of those threads:

This is commonly requested - the problem is that while it does help

reduce boilerplate, it runs counter to the goal of improving clarity.

— Johan

On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

   It is common to shadow optional value name with unwrapped value with
   same name:

   if let someGoodValue = someGoodValue {...}

   What if we'll have a syntax to not repeat the variable name to achieve
   the same target:

   if let someGoodValue! {...}

   What do you think?
   _______________________________________________
   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
_______________________________________________
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

VladimirS · 2016-05-17T15:50:03.000Z

Could you clarify how to use `if case` to achieve the same target as proposed `if let value!` ?
(btw, probably `if let value? {..}` will be better)

···

On 17.05.2016 18:18, Matthew Johnson wrote:

On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

While I've sometimes (early on) wished for a shorter-hand syntax for that
construct, I've never been able to think of something that I thought was
better. I've gotten to the point where I don't particularly mind it anymore.

Regarding the exclamation point specifically, seeing one of those in an
expression context says to me "this thing will die horribly if it is
nil/throws an error". Using it in this context where that's not the case
would probably go against users' expectations.

Agree. If we are going have syntax similar to pattern matching it should
be the same as pattern matching. This would mean using ‘?' rather than
‘!’. However, we already have generalized pattern matching with `if case`
for that. This topic has been debated extensively.

On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

    On 17.05.2016 16:51, Johan Jensen wrote:
     > This was one of the first and most commonly suggested ideas, when
    the Swift
     > Evolution mailing list first started.
     > Chris Lattner sums it up
     >
    <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
     > in one of those threads:
     >
     >> This is commonly requested - the problem is that while it does help
     > reduce boilerplate, it runs counter to the goal of improving clarity.
     >
     > — Johan

    Oh, thank you for letting this know.

    Well, I totally disagree with Chris. And as soon as there was no
    'official'
    proposal and 'official' decision, I'd like to discuss this more.

    I saw a lot of code like
    if let mySomeValue = mySomeValue {} in sources and even in books.
    Plus, I really believe that
    if let mySomeValue! {..} is better in any way: readability, less
    space for
    errors(when you need to repeat the same name) etc

    FWIW, I suggest more explicit variant:
    if let value! {...} // with exclamation mark
    In that "old" proposal there was `if let value {...}`, was not so clear.

    I can't accept an argument that you can use another name - as usually
    'good' name is already 'crafted' for the instance and you want to use
    it in
    next code.
    Otherwise, we need a 'best practice' to name optional variables with some
    prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
    mySomeValueOpt` will have a sense. But as I understand, we don't want to
    use such approach.
    Additionally, when you shadow optional value with same name - you are
    *protecting* yourself from using optional value inside block of unwrapped
    code. IMO it is a good idea.
    And want we or don't want, we already have this practice widely. So I
    believe this(my) proposal will improve the code.

    I'd like to get opinion of the community regarding this feature.

    On 17.05.2016 16:51, Johan Jensen wrote:
    > This was one of the first and most commonly suggested ideas, when
    the Swift
    > Evolution mailing list first started.
    > Chris Lattner sums it up
    >
    <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
    > in one of those threads:
    >
    >> This is commonly requested - the problem is that while it does help
    > reduce boilerplate, it runs counter to the goal of improving clarity.
    >
    > — Johan
    >
    > On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution >> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> <mailto:swift-evolution@swift.org >> <mailto:swift-evolution@swift.org>>> wrote:
    >
    > It is common to shadow optional value name with unwrapped value
    with
    > same name:
    >
    > if let someGoodValue = someGoodValue {...}
    >
    > What if we'll have a syntax to not repeat the variable name to
    achieve
    > the same target:
    >
    > if let someGoodValue! {...}
    >
    > What do you think?
    > _______________________________________________
    > swift-evolution mailing list
    > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    <mailto: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

Patrick_Smith · 2016-05-17T15:31:50.000Z

Here’s a idea, what if you could use a symbol to denote that you want the same name used?

Here’s an interesting sign from music: Repeat sign - Wikipedia

Then you can write (one) of these:

if let |: = mySomeValue {
// Use unwrapped
}

if let mySomeValue = :| {
// Use unwrapped
}

Not sure which one is more clear. Just a totally random idea! I’m not sure about the above symbols, but it would help in other places too from memory to not have to write the same variable name twice.

···

On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

While I've sometimes (early on) wished for a shorter-hand syntax for that construct, I've never been able to think of something that I thought was better. I've gotten to the point where I don't particularly mind it anymore.

Regarding the exclamation point specifically, seeing one of those in an expression context says to me "this thing will die horribly if it is nil/throws an error". Using it in this context where that's not the case would probably go against users' expectations.

Agree. If we are going have syntax similar to pattern matching it should be the same as pattern matching. This would mean using ‘?' rather than ‘!’. However, we already have generalized pattern matching with `if case` for that. This topic has been debated extensively.

On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when the Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
>
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan

Oh, thank you for letting this know.

Well, I totally disagree with Chris. And as soon as there was no 'official'
proposal and 'official' decision, I'd like to discuss this more.

I saw a lot of code like
if let mySomeValue = mySomeValue {} in sources and even in books.
Plus, I really believe that
if let mySomeValue! {..} is better in any way: readability, less space for
errors(when you need to repeat the same name) etc

FWIW, I suggest more explicit variant:
if let value! {...} // with exclamation mark
In that "old" proposal there was `if let value {...}`, was not so clear.

I can't accept an argument that you can use another name - as usually
'good' name is already 'crafted' for the instance and you want to use it in
next code.
Otherwise, we need a 'best practice' to name optional variables with some
prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
mySomeValueOpt` will have a sense. But as I understand, we don't want to
use such approach.
Additionally, when you shadow optional value with same name - you are
*protecting* yourself from using optional value inside block of unwrapped
code. IMO it is a good idea.
And want we or don't want, we already have this practice widely. So I
believe this(my) proposal will improve the code.

I'd like to get opinion of the community regarding this feature.

On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when the Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan
>
> On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution >> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:
>
> It is common to shadow optional value name with unwrapped value with
> same name:
>
> if let someGoodValue = someGoodValue {...}
>
> What if we'll have a syntax to not repeat the variable name to achieve
> the same target:
>
> if let someGoodValue! {...}
>
> What do you think?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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

L_Mihalkovic · 2016-05-18T09:22:06.000Z

I am experimenting with this:

If var! anOptional {
anOptional // unwrapped, shadowing
}

if let! anOptional {
... // same
}

This compiler codebase is truly remarkable, so it should also works with

If var! opt1 where opt1 < 27 {
}

or

if var! opt1, opt2 {
// both unwrapped
}

LM/

···

On May 18, 2016, at 10:21 AM, Daniel Höpfl via swift-evolution <swift-evolution@swift.org> wrote:

Just an idea: Why don’t we think about it similar to try?

var anOptional : String?

let? anOptional { /* use it, but cannot change it */ }
let! anOptional { /* use it, without checking, cannot change it */ }

var? anOptional { /* use it, can also change it, */ }
var! anOptional { /* use it, without checking, can also change it */ }

Is it allowed to set it to nil in the var case? Hard to say.

On 17.05.16 15:43, Vladimir.S via swift-evolution wrote:
It is common to shadow optional value name with unwrapped value with
same name:

if let someGoodValue = someGoodValue {...}

What if we'll have a syntax to not repeat the variable name to achieve
the same target:

if let someGoodValue! {...}

What do you think?
_______________________________________________
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

Austin · 2016-05-17T16:18:16.000Z

If people really want to pursue further sugar here I think it would be worthwhile to explore a direction that hasn’t already been debated extensively. That is why I suggested thinking about `if unwrap`. That said, I really don’t think current state is too bad. It’s definitely not worth expending community energy on this when we clearly have more important things to focus on (like completing generics and ABI).

I agree with Matthew. A marginal increase in developer convenience is, to me, not worth the additional complexity of special purpose syntax.

Austin · 2016-05-17T16:25:21.000Z

A case can be made, of course. My personal opinion is that I don't want to see it in the language at any point. Others are free to agree or disagree.

Austin

···

On May 17, 2016, at 9:21 AM, Matthew Johnson <matthew@anandabits.com> wrote:

On May 17, 2016, at 11:18 AM, Austin Zheng <austinzheng@gmail.com> wrote:

If people really want to pursue further sugar here I think it would be worthwhile to explore a direction that hasn’t already been debated extensively. That is why I suggested thinking about `if unwrap`. That said, I really don’t think current state is too bad. It’s definitely not worth expending community energy on this when we clearly have more important things to focus on (like completing generics and ABI).

I agree with Matthew. A marginal increase in developer convenience is, to me, not worth the additional complexity of special purpose syntax.

I think it’s fair to make a case for the special purpose syntax (which may or may not be accepted). I just don’t think now is the right time to have a debate about it.

anandabits · 2016-05-17T15:48:42.000Z

I always thought a new keyword made more sense here:

if let rebind someValue {
//use shadowed unwrapped value in here
}

if let bind someValue {
//use shadowed unwrapped value in here
}

if let unwrapped someValue {

}

Something along those lines?

I wouldn’t want to see something like this replace the existing `if let` because it doesn’t handle cases where you bind a new name to the result of an expression that returns an optional.

If we did consider something like this it would be simple syntactic sugar for `if let x = x`. Being syntactic sugar for something that is already not too bad means it would need to be as concise as possible. If you want to advocate something like this, maybe consider just `if unwrap`:

if unwrap someValue {
}

···

On May 17, 2016, at 10:41 AM, Brandon Knope <bknope@me.com> wrote:

Brandon

On May 17, 2016, at 11:31 AM, Patrick Smith via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Here’s a idea, what if you could use a symbol to denote that you want the same name used?

Here’s an interesting sign from music: Repeat sign - Wikipedia

Then you can write (one) of these:

if let |: = mySomeValue {
// Use unwrapped
}

if let mySomeValue = :| {
// Use unwrapped
}

Not sure which one is more clear. Just a totally random idea! I’m not sure about the above symbols, but it would help in other places too from memory to not have to write the same variable name twice.

On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

While I've sometimes (early on) wished for a shorter-hand syntax for that construct, I've never been able to think of something that I thought was better. I've gotten to the point where I don't particularly mind it anymore.

Regarding the exclamation point specifically, seeing one of those in an expression context says to me "this thing will die horribly if it is nil/throws an error". Using it in this context where that's not the case would probably go against users' expectations.

Agree. If we are going have syntax similar to pattern matching it should be the same as pattern matching. This would mean using ‘?' rather than ‘!’. However, we already have generalized pattern matching with `if case` for that. This topic has been debated extensively.

On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when the Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
>
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan

Oh, thank you for letting this know.

Well, I totally disagree with Chris. And as soon as there was no 'official'
proposal and 'official' decision, I'd like to discuss this more.

I saw a lot of code like
if let mySomeValue = mySomeValue {} in sources and even in books.
Plus, I really believe that
if let mySomeValue! {..} is better in any way: readability, less space for
errors(when you need to repeat the same name) etc

FWIW, I suggest more explicit variant:
if let value! {...} // with exclamation mark
In that "old" proposal there was `if let value {...}`, was not so clear.

I can't accept an argument that you can use another name - as usually
'good' name is already 'crafted' for the instance and you want to use it in
next code.
Otherwise, we need a 'best practice' to name optional variables with some
prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
mySomeValueOpt` will have a sense. But as I understand, we don't want to
use such approach.
Additionally, when you shadow optional value with same name - you are
*protecting* yourself from using optional value inside block of unwrapped
code. IMO it is a good idea.
And want we or don't want, we already have this practice widely. So I
believe this(my) proposal will improve the code.

I'd like to get opinion of the community regarding this feature.

On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when the Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan
>
> On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution >>>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> wrote:
>
> It is common to shadow optional value name with unwrapped value with
> same name:
>
> if let someGoodValue = someGoodValue {...}
>
> What if we'll have a syntax to not repeat the variable name to achieve
> the same target:
>
> if let someGoodValue! {...}
>
> What do you think?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto: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

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

anandabits · 2016-05-17T15:58:35.000Z

Could you clarify how to use `if case` to achieve the same target as proposed `if let value!` ?
(btw, probably `if let value? {..}` will be better)

You don’t get the same implicit match that this idea proposes, but you do get the full power of pattern matching. And you get to use the ? pattern.

let i: Int? = 42
if case let i? = i {
}

The differences in the suggestion here is to allow you to drop case and implicitly match on the value currently bound to the name in the pattern, rebinding using the pattern if a match happens.

If people really want to pursue further sugar here I think it would be worthwhile to explore a direction that hasn’t already been debated extensively. That is why I suggested thinking about `if unwrap`. That said, I really don’t think current state is too bad. It’s definitely not worth expending community energy on this when we clearly have more important things to focus on (like completing generics and ABI).

···

On May 17, 2016, at 10:50 AM, Vladimir.S <svabox@gmail.com> wrote:

On 17.05.2016 18:18, Matthew Johnson wrote:

On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

While I've sometimes (early on) wished for a shorter-hand syntax for that
construct, I've never been able to think of something that I thought was
better. I've gotten to the point where I don't particularly mind it anymore.

Regarding the exclamation point specifically, seeing one of those in an
expression context says to me "this thing will die horribly if it is
nil/throws an error". Using it in this context where that's not the case
would probably go against users' expectations.

Agree. If we are going have syntax similar to pattern matching it should
be the same as pattern matching. This would mean using ‘?' rather than
‘!’. However, we already have generalized pattern matching with `if case`
for that. This topic has been debated extensively.

On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

   On 17.05.2016 16:51, Johan Jensen wrote:
    > This was one of the first and most commonly suggested ideas, when
   the Swift
    > Evolution mailing list first started.
    > Chris Lattner sums it up
    >
   <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
    > in one of those threads:
    >
    >> This is commonly requested - the problem is that while it does help
    > reduce boilerplate, it runs counter to the goal of improving clarity.
    >
    > — Johan

   Oh, thank you for letting this know.

   Well, I totally disagree with Chris. And as soon as there was no
   'official'
   proposal and 'official' decision, I'd like to discuss this more.

   I saw a lot of code like
   if let mySomeValue = mySomeValue {} in sources and even in books.
   Plus, I really believe that
   if let mySomeValue! {..} is better in any way: readability, less
   space for
   errors(when you need to repeat the same name) etc

   FWIW, I suggest more explicit variant:
   if let value! {...} // with exclamation mark
   In that "old" proposal there was `if let value {...}`, was not so clear.

   I can't accept an argument that you can use another name - as usually
   'good' name is already 'crafted' for the instance and you want to use
   it in
   next code.
   Otherwise, we need a 'best practice' to name optional variables with some
   prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
   mySomeValueOpt` will have a sense. But as I understand, we don't want to
   use such approach.
   Additionally, when you shadow optional value with same name - you are
   *protecting* yourself from using optional value inside block of unwrapped
   code. IMO it is a good idea.
   And want we or don't want, we already have this practice widely. So I
   believe this(my) proposal will improve the code.

   I'd like to get opinion of the community regarding this feature.

   On 17.05.2016 16:51, Johan Jensen wrote:
   > This was one of the first and most commonly suggested ideas, when
   the Swift
   > Evolution mailing list first started.
   > Chris Lattner sums it up
   >
   <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html>
   > in one of those threads:
   >
   >> This is commonly requested - the problem is that while it does help
   > reduce boilerplate, it runs counter to the goal of improving clarity.
   >
   > — Johan
   >
   > On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution >>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> <mailto:swift-evolution@swift.org >>> <mailto:swift-evolution@swift.org>>> wrote:
   >
   > It is common to shadow optional value name with unwrapped value
   with
   > same name:
   >
   > if let someGoodValue = someGoodValue {...}
   >
   > What if we'll have a syntax to not repeat the variable name to
   achieve
   > the same target:
   >
   > if let someGoodValue! {...}
   >
   > What do you think?
   > _______________________________________________
   > swift-evolution mailing list
   > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
   <mailto: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

anandabits · 2016-05-17T16:08:39.000Z

Being syntactic sugar for something that is already not too bad

Well.. Personally I feel like construction `if let someMyValue = someMyValue` is bad exactly because of this the same repeated name. Anywhere I see repeated code, I feel like this is not good.

I generally agree, but it’s pretty trivial repetition in this case. And like others have noted, if you need to do this often it might be worth looking at other aspects of how your code is structured.

means it
would need to be as concise as possible. If you want to advocate something
like this, maybe consider just `if unwrap`:

if unwrap someValue {
}

Yes, IMO the best idea for this feature for this moment. Clear and explicit. Why not?

If immediate consensus forms, sure why not? But I don’t think it’s worth extended discussion.

···

On May 17, 2016, at 11:06 AM, Vladimir.S <svabox@gmail.com> wrote:
On 17.05.2016 18:48, Matthew Johnson via swift-evolution wrote: