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