> On Dec 19, 2015, at 1:41 PM, Dennis Lysenko <[email protected]> 
> wrote:
> 
> Shadowing is good in this case because it lets you capture constant values 
> for the exact scope in which you need them.
> 
That is completely independent of shadowing.  You do that even if you choose 
different names inside the block from outside.
> 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.
> 
"More descriptive" ≠ "more readable".  When writing, we don't go into reams of 
detail about everything; we go into detail about the salient things.  We have 
pronouns for a reason, e.g. "when a person arriving at the refrigerator opens 
the door, she sees what's inside; then she decides whether she wants it."  
"She" is a short name used in a localized context as a stand-in for a 
more-descriptive phrase, "a person arriving at the refrigerator".  Repeating 
the more descriptive phrase would harm readability.

> 
> On Sat, Dec 19, 2015, 4:34 PM Dennis Lysenko <[email protected] 
> <mailto:[email protected]>> 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 
> <[email protected] <mailto:[email protected]>> wrote:
>> On Dec 19, 2015, at 12:37 PM, ilya via swift-evolution 
>> <[email protected] <mailto:[email protected]>> 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 
>> <[email protected] <mailto:[email protected]>> 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 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>>> 
>>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution 
>>>> <[email protected] <mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>  _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> -Dave
> 
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

-Dave



_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to