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
> <[email protected]> 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
> <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
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>>
>>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
>>> <[email protected] <mailto:[email protected]>> 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
>>>
>>> <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
>>> >
>>> > <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
>>> > <[email protected] <mailto:[email protected]>
>>> > <mailto:[email protected] <mailto:[email protected]>>>
>>> > 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
>>> > [email protected] <mailto:[email protected]>
>>> > <mailto:[email protected] <mailto:[email protected]>>
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> >
>>> >
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
