[swift-evolution] Proposal Sketch: simplify optional unwrapping syntax
Dennis Lysenko
dennis.s.lysenko at gmail.com
Sat Dec 19 15:34:17 CST 2015
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151219/67eb7c13/attachment.html>
More information about the swift-evolution
mailing list