[Idea] "guard not let" optional binding

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.

···

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

Brandon

···

On May 17, 2016, at 11:31 AM, Patrick Smith via swift-evolution <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&gt;
> 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&gt;
> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

It’s not just about being concise, but reducing repeated code:

It would be syntactic sugar for this:
if case .Some(let optional) = optional {
    
}

But yes, unwrap makes much more sense.

At the end of the day, I am not too bothered by if let syntax, but if we could clear up some of the repetitive code and all the =’s while still remaining clear, I would not oppose it!

Brandon

···

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

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

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

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&gt;
> 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&gt;
> 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

Now *that* reminds me of the _ voodoo in perl... and i was under the impression that magic symbols are not highly regarded in swift (which I really appreciate!!)

Regards
LM
(From mobile)

···

On May 17, 2016, at 5:31 PM, Patrick Smith via swift-evolution <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> wrote:

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.

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> 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&gt;
> 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&gt;
> 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

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

Regards
LM
(From mobile)

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

+25. Will look at the parser to see what the impl cost is (although chris has clearly stated that pure sugaring is not yet on the agenda to prevent creating cruft rather than addressing the root causes)

···

On May 17, 2016, at 5:48 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

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

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.

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> 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&gt;
> 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&gt;
> 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

_______________________________________________
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

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.

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?

···

On 17.05.2016 18:48, Matthew Johnson via swift-evolution wrote:

Well.. Although I agree that this is not 'big deal' feature, I believe it will slightly improve the experience of coding in Swift, similar to other small features.

Must we stop to discuss anything else than "completing generics and ABI"?
Or it is worth to discuss interesting features even if it will not be included in Swift 3.0 ? (I.e. probably can be included in later versions).

···

On 17.05.2016 18:58, Matthew Johnson wrote:

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

All is good, if it is in *my* code ;-) But I often see this pattern in *others* code and I don't want to see it in others code :-)

···

On 17.05.2016 19:08, Matthew Johnson wrote:

it might be worth looking at other aspects of how your code is structured.

interestingly enough, it looks like a truly simple task... the grammar has 2 types of BindingKind at that location BK_Let and BK_Var, which means that a single shorthand notation will assume one of the other, which means that if it does assume one, then it better be explicit about it, or alternatively there ought to be 2 shorthands for the 2 binding kinds. i.e. :

if unwrapped_var xxxx {
}

and

if unwrapped_let xxxx {
}

or perhaps even easier to express as:

if let! xxxx {
   // xxxx is unwrapped LET
}

and

if var! xxxx {
   // xxxx is unwrapped VAR
}

From what I could understand of the compiler, these would seem like localized small scale changes, but unfortunately still entirely out of the scope of 3.0 ( not to mention probably still not bringing the clarity chris identified as main blocker).

Ideas like this one, that are both simple in scope but out of the main focus might still be worth collecting somewhere as a series of “if you would like to get familiar with the compiler codebase to try and help at a future date with more serious items, we suggest that you look into finding the least intrusive way to implement any of these features.. we guaranty that there is a simple way to build them”. They might prove a good training ground for would be helpers.

Apologies for taking your time.
/LM

···

On May 17, 2016, at 5:48 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

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

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

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&gt;
> 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&gt;
> 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

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

Adding a keyword `unwrap` might reduce the code repetition but I think it will be confusing to use a keyword to unwrap something while we already have a way to do that.

I think two ways to do one thing impacts clarity.

I understand that `unwrap` is a replacement for Optional Binding and optional binding is slightly different from just unwrapping but look at it from the perspective of someone new coming to Swift. Keyword `unwrap` straight away gives a notion of unwrapping an optional instead of the underlying meaning of Optional Binding.

Opinion on `if let value!`

I am not convinced with this style as well and for the same reason of clarity. Here “!” gives a notion that you are just unwrapping “value” instead of optional binding value. Again look at it from the perspective of someone new coming to the Swift.

I think it is equally important to make Swift understandable for newcomers while making it convenient for experienced programmers. Sometimes these newcomers can be entirely new to the concept of programming. So, please keep it in mind while improving the language.

I might be absolutely wrong as I am one of the newcomers who is trying to understand basics from experienced ones here by reading these emails. If that is the case please correct me.

Thanks

-Krishna

···

On May 17, 2016, at 9:18 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

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

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

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&gt;
> 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&gt;
> 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

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

Would it be possible to drop the "if"? I don't see why we need it.

···

On 2016-05-18 11:22, LM wrote:

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

Very interesting. But, as I can see, no community's support for this feature.

···

On 18.05.2016 12:22, LM wrote:

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

The idea to process the 'if' block only if anOptional is not null

In case of
let! anOptional {
}
IMO it is not clear that this block will be executed *only* if anOptional is not null.

if let! anOptional {
  // here only if anOptional != null
}
- seems like similar to standard 'if let' construction so should not confuse too much and IMO will be remembered after the first appearance/using.

···

On 18.05.2016 15:15, Daniel Höpfl via swift-evolution wrote:

Would it be possible to drop the "if"? I don't see why we need it.

On 2016-05-18 11:22, LM wrote:

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

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

Very interesting. But, as I can see, no community's support for this feature.

I don't mind the lack of interest. chris was very clear that this kind of syntax sugaring is out of scope for 3.0 in general, and that he did not want this one in particular.

my goal is just to learn the compiler codebase, and over the last couple days its been a great teaching tool. I'll leave the code somewhere for others to play with it. It would be very nice of the core team to have a small list somewhere of little brain teasers like this one that they know are do-able in a couple days without their help, to learn to get familiar with what's what and where

···

On May 18, 2016, at 2:37 PM, Vladimir.S <svabox@gmail.com> wrote:

On 18.05.2016 12:22, LM wrote:
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

That's the idea of "let?".
"let!" would always execute the block (and crash if the optional is nil.)

"if let!" is meaningless: "let!" would be true (if the optional is set) or crash (if the optional is nil).

···

On 2016-05-18 14:27, Vladimir.S wrote:

The idea to process the 'if' block only if anOptional is not null

In case of
let! anOptional {
}
IMO it is not clear that this block will be executed *only* if
anOptional is not null.

if let! anOptional {
// here only if anOptional != null
}
- seems like similar to standard 'if let' construction so should not
confuse too much and IMO will be remembered after the first
appearance/using.

On 18.05.2016 15:15, Daniel Höpfl via swift-evolution wrote:

Would it be possible to drop the "if"? I don't see why we need it.

On 2016-05-18 11:22, LM wrote:

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

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

I understand *your* idea of let?/let! etc without 'if', but personally I don't support it. I think `if` must be used in this feature.

In any case I feel like this idea is not accepted by community, so it seems like there is no sense to discuss its details.

···

On 18.05.2016 16:12, Daniel Höpfl wrote:

That's the idea of "let?".
"let!" would always execute the block (and crash if the optional is nil.)

"if let!" is meaningless: "let!" would be true (if the optional is set) or
crash (if the optional is nil).

On 2016-05-18 14:27, Vladimir.S wrote:

The idea to process the 'if' block only if anOptional is not null

In case of
let! anOptional {
}
IMO it is not clear that this block will be executed *only* if
anOptional is not null.

if let! anOptional {
// here only if anOptional != null
}
- seems like similar to standard 'if let' construction so should not
confuse too much and IMO will be remembered after the first
appearance/using.

On 18.05.2016 15:15, Daniel Höpfl via swift-evolution wrote:

Would it be possible to drop the "if"? I don't see why we need it.

On 2016-05-18 11:22, LM wrote:

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

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

I came across this thread while looking for a solution to this.

Maybe unwrapping can happen implicitly in some very specific cases such as the ones described below?

guard someValue == nil else {
   // someValue is unwrapped here
   return
}

And

guard someValue != nil else {
    return
}
// someValue is unwrapped here

The same logic could be used for if blocks.