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

[Dennis Lysenko]

Another argument is in a large block with several bound optionals, reusing
names prevents people from accidentally accessing optionals that were
already bound to non optional values.

We were all skeptical, I think, of reusing names in optional binding at
first (I thought it looked ugly), but I grew accustomed to it and it works
really well. Even Ray Wenderlich's style guide (only comprehensive one I've
come across so far) suggests doing that. May I ask if those who oppose
shadowing in optional binding have ever actually given it a chance?

On Sat, Dec 19, 2015, 4:41 PM Dennis Lysenko via swift-evolution <
swift-evolution at swift.org> wrote:

> Shadowing is good in this case because it lets you capture constant values
> for the exact scope in which you need them. This helps avoid overhead of
> repeated getters and method calls. Using shorter names is automatically
> less descriptive; otherwise, people would advocate using abbreviations in
> property names, which is a stylistic and readability faux pas.
>
> On Sat, Dec 19, 2015, 4:34 PM Dennis Lysenko <dennis.s.lysenko at gmail.com>
> wrote:
>
>> Disagree. Short names are less descriptive and less readable. And saying
>> "shadowing is bad" without any argument is just silly for a mailing list.
>>
>> On Sat, Dec 19, 2015, 3:57 PM Dave Abrahams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> On Dec 19, 2015, at 12:37 PM, ilya via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> I prefer
>>>
>>> if let vc = someInterestingViewConroller {
>>> vc.doSomething()
>>> }
>>>
>>> - Explicit is better than implicit
>>> - shadowing is bad
>>> - now there's no ambiguity about how to change the original property.
>>>
>>> Therefore I'm -1 on any proposal that hides explicit name binding and/or
>>> increases shadowing, including let foo and unwrap foo.
>>>
>>>
>>> +1 to that.  IMO re-using the same name for the unwrapped version of an
>>> optional variable does not help readability, and I don't want to encourage
>>> it.  In a localized context like this, a short name is often better anyway
>>> as it declutters the code inside the block.
>>>
>>>
>>> On Sat, Dec 19, 2015 at 21:31 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
>>>
>>>
>>> -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/20151219/eb5633d0/attachment.html>