[swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Cihat Gündüz]

> However, you may be interested in the last email Chris sent in this chain with regards to shortening it to just "let foo":
> 
> "This is commonly requested - the problem is that while it does help reduce boilerplate, it runs counter to the goal of improving clarity."
> 
> He's got a point; "if let foo = bar" makes sense in a way, but just "if let foo" is a bit nonsensical to me when I take my mind outside of the narrow swift mindset I tend to get into. This extends to decorating the foo with a question mark or a bang, imo. 

Thank you for the feedback, Dennis. That post you quote is amongst the ones I read and it is even the reason I am suggesting these alternatives. Let me explain my thinking behind my suggestions a bit. I agree with Chris that `if let foo { /* code */ }` isn’t very readable mainly because there is no action done on the `foo` like a `= bar` or something else. But I also had the thought ‚why do I need to type this twice, can’t this be optimized?‘ quite a few times when I used `if let foo = foo { /* code */ }` in practice.

So that’s why I thought there must be a way. First I started with something that contained the `=` sign also using the shorthand `x += 1` for `x = x + 1` as an inspiration. That lead to things like these:

if let foo = _ { /* code */ }
if let foo = ! { /* code */ }
if let foo ?= _ { /* code */ }
if foo ?= foo { /* code */ }
if let foo ?= { /* code */ }

But being honest to myself I thought all of those were even less readable then `if let foo { /* code */ }`. But once I dropped the `=` sign like in `if let foo! { /* code */ }` I started to like the idea and still found it readable.

I generally read let like a ‚define constant with name‘ and a ! like ‚force unwrap value‘ so I would read `let foo!` as ‚define constant with name and force unwrap value`. But I agree that ? may be more correct which I read as `try to unwrap value only continuing if unwrap succeeds` so `let foo?` would read as `define constant with name and try to unwrap only continuing if unwrap succeeds`.

So in conclusion to me `if let foo { }` isn’t readable but `if let foo? { }` is. That is only my opinion though.

> 
> On Sat, Dec 19, 2015 at 7:02 PM Cihat Gündüz <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I’ve only read the last couple of posts but has anybody already suggested using something like this:
> 
> if let foo! {
>   // code that uses foo
> }
> 
> People already know that the ! is unwrapping a value and that let is defining a new constant. So why not combine those two?
> Alternatively it could also be:
> 
> if let foo? {
>   // code that uses foo
> }
> 
> What do you think?
> 
> – Cihat
> 
>> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>>> 
>>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I was going to suggest something similar (a hard naming problem also):
>>> 
>>> if has foo {
>>>     // foo is now unwrapped and non-optional
>>> }
>>> 
>>> guard has foo else { return }
>>> 
>>> Does the same thing as `let foo = foo` in practice, but places it in a somewhat different mental model. Instead of unwrapping and immediately assigning to a new constant with the same name (which just looks kind of silly, like some magic voodoo ritual), it sort of asserts that we “have” foo (i.e. it’s not nil), and therefore from that point it can just be treated as non-optional.
>>> 
>>> IMHO this, although introduces a new keyword, makes more sense than trying to reuse “let” in a context where it seems nonsensical. Perhaps this would be closer to Swift’s goals, by reducing very common boilerplate, but without harming clarity in a way adding a new meaning to “let” would.
>>> 
>>> Curious to hear Chris Lattner’s opinion :-) 
>> 
>> IANACL (I am not a Chris Lattner) but, FWIW, several of us are uncomfortable with the idea that a single declared property might have different static types in different regions of code.
>> 
>>> 
>>> — Radek
>>> 
>>>> On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> What if we made the keyword "unwrap"? 
>>>> 
>>>> if unwrap someViewController {
>>>> // now there is a shadowing nonoptional (unwrapped) variable of the same name only within this scope, boiling down to simple syntactic sugar for optional binding and it is fairly clear. 
>>>> } 
>>>> 
>>>> 
>>>> On Sat, Dec 19, 2015, 1:31 PM Kevin Wooten via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> As much fun as it to example with foo, I would argue the opposite when you use some real world variable names:
>>>> 
>>>> if let someInterestingViewConroller = someInterestingViewConroller {
>>>> }
>>>> 
>>>> vs
>>>> 
>>>> If let someInterestingViewConroller {
>>>> }
>>>> 
>>>> We know what let does and it should be enough to impart the necessary information for this statement.
>>>> 
>>>> When it comes to newcomers I think you'd be hard pressed to find somebody who'd be able to understand either form without teaching; so not losing much there.
>>>> 
>>>> 
>>>> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> 
>>>>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>> I’ve had similar ideas to this. Instead of ditching the if let syntax altogether, another approach would be to use the existing name if no new name is given, so that this code:
>>>>>> 
>>>>>> 	if let foo = foo { /* use foo */ }
>>>>>> 
>>>>>> could become this code:
>>>>>> 
>>>>>> 	if let foo { /* use foo */ }
>>>>>> 
>>>>>> In both cases, foo is non-optional inside the braces. If you gave it another name with the if let syntax, that would work as it does today.
>>>>> 
>>>>> Hi Jeff,
>>>>> 
>>>>> This is commonly requested - the problem is that while it does help reduce boilerplate, it runs counter to the goal of improving clarity.
>>>>> 
>>>>> -Chris
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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>
>> -Dave
>> 
>> 
>> 
>>  _______________________________________________
>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/19610570/attachment.html>