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

[Dennis Lysenko]

Cihat, if either of the two you proposed I would prefer "let foo?" as the
bang (!), outside of logical negation, carries a meaning of "this is
dangerous and something could go wrong at runtime here". Evidenced by its
only other uses--try!, force-unwrapping, and implicitly unwrapped optionals.

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.

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/01348bdf/attachment.html>