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

Tue Jan 5 16:37:12 CST 2016

That said, I am in favor of automatic type narrowing. As long as it doesn't
complicate the compiler considerably (if it does, there's little reason to
replace optional binding), it's no less confusing than shadowing was when I
first saw it, and once you get used to it (shouldn't be more than a day):
it is less verbose and perhaps more intuitive (I've found myself reacting
to optionals saying "duh, I've already guarded that X is nonnull on this
codepath, why would I have to unwrap it again?" in Swift).

On Tue, Jan 5, 2016 at 5:35 PM Dennis Lysenko <dennis.s.lysenko at gmail.com>
wrote:

> Thorsten,
>
> Not that I disapprove (Kotlin does the same and it's great), the precedent
> seems to have already been set in people's minds that there won't be any
> kind of implicit type narrowing and I predict a fair few will respond with
> "You can already do that with optional binding, and I'm uncomfortable
> seeing a variable change type in an inner scope" even though shadowing
> achieves exactly the same aim. The same happened the last time that type
> narrowing was mentioned.
>
>
> On Tue, Jan 5, 2016 at 5:27 PM Thorsten Seitz via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Ceylon has type narrowing (not only for optional unwrapping but for type
>> checks as well):
>> http://ceylon-lang.org/documentation/1.2/tour/types/#narrowing_the_type_of_an_object_reference
>>
>> It always struck me as quite natural to do this.
>>
>> -Thorsten
>>
>> Am 02.01.2016 um 06:08 schrieb Tyler Fleming Cloutier via swift-evolution
>> <swift-evolution at swift.org>:
>>
>>
>> Whoops, errant button tap.
>>
>> I've always thought that,
>>
>> if let foo = foo? {
>>
>> }
>>
>> makes more sense than
>>
>> if let foo = foo {
>>
>> }
>>
>> as the ? indicates that you are unwrapping the optional and then
>> assigning it to the new variable.
>>
>> The current syntax must seem incomprehensible/redundant to those new to
>> Swift. This obviously doesn't help with the verbosity at all, but it seems
>> to be more consistent with ? being the operator for unwrapping.
>>
>> Of course there is also the current optional pattern matching syntax:
>>
>> if case let foo? = foo {
>>
>> }
>>
>> This accomplishes the same thing and is somewhat less perplexing than "if
>> let foo = foo", but must still be baffling to a new user.
>>
>> You could even have:
>>
>> if foo? {
>>     foo.blah()
>> }
>>
>> Which would not create a shadow local variable but would have the same
>> semantics as
>>
>> foo?.blah()
>>
>> in that is just providing conditional access to the variable if it's not
>> .None. Not sure if this direct access is desired as it is still magical
>> scoped type manipulation without declaring a new variable.
>>
>>
>> Tyler
>>
>>
>> On Jan 1, 2016, at 11:44 PM, Tyler Cloutier <cloutiertyler at aol.com>
>> wrote:
>>
>> I've always thought that,
>>
>> if let foo = foo? {
>>
>> }
>>
>> makes more sense than
>>
>> if let foo = foo {
>>
>> }
>>
>> as the ? indicates that you are unwrapping the optional and then
>> assigning it to the new variable
>>
>> On Dec 19, 2015, at 7:02 PM, Cihat Gündüz via swift-evolution <
>> 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
>>
>>
>>  _______________________________________________
>> 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/20160105/bcc146d4/attachment-0001.html>