Re: [swift-evolution] [Idea] if let value!

[LM via swift-evolution]

> On May 18, 2016, at 2:37 PM, Vladimir.S  wrote:
> 
> 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 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 
>>>  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

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via 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
 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



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

Re: [swift-evolution] [Idea] if let value!

[Daniel Höpfl via 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
 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

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

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via 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 
 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

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via 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
 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

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

Re: [swift-evolution] [Idea] if let value!

[Daniel Höpfl via 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 
 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

Re: [swift-evolution] [Idea] if let value!

[LM via swift-evolution]

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

Re: [swift-evolution] [Idea] if let value!

[Daniel Höpfl via swift-evolution]

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

Re: [swift-evolution] [Idea] if let value!

[Krishna Kumar via 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 
>  wrote:
> 
>> 
>> On May 17, 2016, at 10:41 AM, Brandon Knope > > 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 
>>> > 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: 
>>> https://en.wikipedia.org/wiki/Repeat_sign 
>>> 
>>> 
>>> 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 
 > wrote:
 
> 
> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
> > 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 
> > 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
>  >
>   
> >
>  > in one of those threads:
>  >
>  >> This is commonly 

Re: [swift-evolution] [Idea] if let value!

[L Mihalkovic via swift-evolution]

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

and 

if unwrapped_let  {
}

or perhaps even easier to express as:

if let!  {
   //  is unwrapped LET
}

and 

if var!  {
   //  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 
>  wrote:
> 
> 
>> On May 17, 2016, at 10:41 AM, Brandon Knope > > 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 
>>> > 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: 
>>> https://en.wikipedia.org/wiki/Repeat_sign 
>>> 
>>> 
>>> 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 
 > wrote:
 
> 
> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
> > 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 
> > 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
>  >
>   
> >
>  > in one of those threads:
> 

Re: [swift-evolution] [Idea] if let value!

[Austin Zheng via swift-evolution]

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  wrote:
> 
> 
>> On May 17, 2016, at 11:18 AM, Austin Zheng  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.

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

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via swift-evolution]

On 17.05.2016 19:08, Matthew Johnson wrote:

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


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

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

Re: [swift-evolution] [Idea] if let value!

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 11:18 AM, Austin Zheng  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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via swift-evolution]

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


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

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

Re: [swift-evolution] [Idea] if let value!

[Austin Zheng via swift-evolution]

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

Re: [swift-evolution] [Idea] if let value!

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 11:06 AM, Vladimir.S  wrote:
> 
> On 17.05.2016 18:48, Matthew Johnson via swift-evolution wrote:
>> 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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[LM via swift-evolution]

Regards
LM
(From mobile)

> On May 17, 2016, at 5:48 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On May 17, 2016, at 10:41 AM, Brandon Knope  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 {
> }
> 
> 

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


> 
>> 
>> Brandon
>> 
>> 
>>> On May 17, 2016, at 11:31 AM, Patrick Smith via swift-evolution 
>>>  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: 
>>> https://en.wikipedia.org/wiki/Repeat_sign
>>> 
>>> 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 
>  wrote:
> 
> 
> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>  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 
>>  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
>>  >
>> 
>>  > 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 

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via swift-evolution]

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

 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?

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

Re: [swift-evolution] [Idea] if let value!

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 10:50 AM, Vladimir.S  wrote:
> 
> 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 17.05.2016 18:18, Matthew Johnson wrote:
>> 
>>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution
>>> > 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
>>> > 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
>>> >
>>>
>>> 
>>> > 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
>>>>
>>>
>>> 
>>>> 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
>>>> 

Re: [swift-evolution] [Idea] if let value!

[Brandon Knope via 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  wrote:
> 
> 
>> On May 17, 2016, at 10:41 AM, Brandon Knope > > 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 
>>> > 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: 
>>> https://en.wikipedia.org/wiki/Repeat_sign 
>>> 
>>> 
>>> 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 
 > wrote:
 
> 
> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
> > 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 
> > 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
>  >
>   
> >
>  > 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 

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via swift-evolution]

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


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


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

Re: [swift-evolution] [Idea] if let value!

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 10:41 AM, Brandon Knope  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 
>> > 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: 
>> https://en.wikipedia.org/wiki/Repeat_sign 
>> 
>> 
>> 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 
>>> > wrote:
>>> 
 
 On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
 > 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 
 > 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
  >
 >
  > 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.

Re: [swift-evolution] [Idea] if let value!

[Brandon Knope via swift-evolution]

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 
>  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: 
> https://en.wikipedia.org/wiki/Repeat_sign 
> 
> 
> 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 
>> > wrote:
>> 
>>> 
>>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>>> > 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 
>>> > 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
>>>  >
>>> >>  
>>> >
>>>  > 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
>>> > >> >  
>>> > >
>>> > 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 

Re: [swift-evolution] [Idea] if let value!

[LM via 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 
>  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: 
> https://en.wikipedia.org/wiki/Repeat_sign
> 
> 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 
>>>  wrote:
>>> 
>>> 
>>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>>>  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 
  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
  >
 
  > 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
 > 
 > 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
 > > 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 

Re: [swift-evolution] [Idea] if let value!

[LM via swift-evolution]

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 
>  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 
>>  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 
>>  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
>> 
>>> 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
>>> 
>>> 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
>>> > 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
> 
> ___
> swift-evolution mailing 

Re: [swift-evolution] [Idea] if let value!

[Patrick Smith via swift-evolution]

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: https://en.wikipedia.org/wiki/Repeat_sign

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 
>  wrote:
> 
>> 
>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>> > 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 
>> > 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
>>  >
>> >  
>> >
>>  > 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
>> > > >  
>> > >
>> > 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
>> >  
>> > >> 
>> > 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 

Re: [swift-evolution] [Idea] if let value!

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>  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 
> > 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
>  >
>   
> >
>  > 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
> >  >  
> > >
> > 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
> >  
> > >> 
> > 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

Re: [swift-evolution] [Idea] if let value!

[Sean Heber via swift-evolution]

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

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

Re: [swift-evolution] [Idea] if let value!

[Tony Allevato via swift-evolution]

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

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via swift-evolution]

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
> 


> 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

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

Re: [swift-evolution] [Idea] if let value!

[Johan Jensen via swift-evolution]

This was one of the first and most commonly suggested ideas, when the Swift
Evolution mailing list first started.
Chris Lattner sums it up

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