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

Sat Dec 19 22:14:57 CST 2015

@Kevin: That is why I'm suggesting if unwrap foo {, because I believe it's
clearer than either. I was trying to say, though, that "if let foo = bar",
one of the first things you learn in swift, transitions naturally to "if
let foo = foo", though slightly disorienting at first, but will be
disconnected from just "if let foo" due to being in a fundamentally
different format.

@Cihat: Aha, interesting points. I still think a more explicit keyword like
"unwrap" or "bind" would achieve a bit more clarity.

On Sat, Dec 19, 2015 at 7:47 PM Cihat Gündüz <CihatGuenduez at posteo.de>
wrote:

> 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>
> 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>:
>>
>>
>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution <
>> 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> 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> 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> wrote:
>>>
>>>
>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution <
>>> 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
>>> 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
>>>
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> 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
>>
>>
>> -Dave
>>
>>
>>
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> 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/20151220/9d4a0925/attachment.html>