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

Wed Jan 6 04:00:46 CST 2016

We should add an unless one to compliement it :)

unless foo?
{
}

On Wed, Jan 6, 2016 at 6:16 AM, Thorsten Seitz via swift-evolution <
swift-evolution at swift.org> wrote:

> +1
>
> Type narrowing would also fit nicely with union types (as demonstrated in
> Ceylon).
>
> -Thorsten
>
> Am 05.01.2016 um 23:37 schrieb Dennis Lysenko <dennis.s.lysenko at gmail.com
> >:
>
> 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
>>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>

-- 
 Wizard
james at supmenow.com
+44 7523 279 698
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160106/1fcdc6a7/attachment-0001.html>