[swift-evolution] [Idea] if let value!
Krishna Kumar
kkdevenda at gmail.com
Wed May 18 02:49:59 CDT 2016
Adding a keyword `unwrap` might reduce the code repetition but I think it will be confusing to use a keyword to unwrap something while we already have a way to do that.
I think two ways to do one thing impacts clarity.
I understand that `unwrap` is a replacement for Optional Binding and optional binding is slightly different from just unwrapping but look at it from the perspective of someone new coming to Swift. Keyword `unwrap` straight away gives a notion of unwrapping an optional instead of the underlying meaning of Optional Binding.
Opinion on `if let value!`
I am not convinced with this style as well and for the same reason of clarity. Here “!” gives a notion that you are just unwrapping “value” instead of optional binding value. Again look at it from the perspective of someone new coming to the Swift.
I think it is equally important to make Swift understandable for newcomers while making it convenient for experienced programmers. Sometimes these newcomers can be entirely new to the concept of programming. So, please keep it in mind while improving the language.
I might be absolutely wrong as I am one of the newcomers who is trying to understand basics from experienced ones here by reading these emails. If that is the case please correct me.
Thanks
-Krishna
> On May 17, 2016, at 9:18 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>
>>
>> On May 17, 2016, at 10:41 AM, Brandon Knope <bknope at me.com <mailto:bknope at me.com>> wrote:
>>
>> I always thought a new keyword made more sense here:
>>
>> if let rebind someValue {
>> //use shadowed unwrapped value in here
>> }
>>
>> if let bind someValue {
>> //use shadowed unwrapped value in here
>> }
>>
>>
>> if let unwrapped someValue {
>>
>> }
>>
>> Something along those lines?
>
> I wouldn’t want to see something like this replace the existing `if let` because it doesn’t handle cases where you bind a new name to the result of an expression that returns an optional.
>
> If we did consider something like this it would be simple syntactic sugar for `if let x = x`. Being syntactic sugar for something that is already not too bad means it would need to be as concise as possible. If you want to advocate something like this, maybe consider just `if unwrap`:
>
> if unwrap someValue {
> }
>
>
>
>>
>> Brandon
>>
>>
>>> On May 17, 2016, at 11:31 AM, Patrick Smith via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> Here’s a idea, what if you could use a symbol to denote that you want the same name used?
>>>
>>> Here’s an interesting sign from music: 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>
>>>>>
>>>>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>
>>>>> While I've sometimes (early on) wished for a shorter-hand syntax for that construct, I've never been able to think of something that I thought was better. I've gotten to the point where I don't particularly mind it anymore.
>>>>>
>>>>> Regarding the exclamation point specifically, seeing one of those in an expression context says to me "this thing will die horribly if it is nil/throws an error". Using it in this context where that's not the case would probably go against users' expectations.
>>>>
>>>> Agree. If we are going have syntax similar to pattern matching it should be the same as pattern matching. This would mean using ‘?' rather than ‘!’. However, we already have generalized pattern matching with `if case` for that. This topic has been debated extensively.
>>>>
>>>>>
>>>>>
>>>>> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 <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
>>>>> > <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> >
>>>>> >
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160518/c5a30d31/attachment.html>
More information about the swift-evolution
mailing list