[swift-evolution] [Review] SE-0025 Scoped Access Level

[Stephen Celis]

> On Feb 28, 2016, at 2:18 AM, Nate Cook <natecook at gmail.com> wrote:
> 
> Sure. you can see the rotate code here:
> 	https://gist.github.com/natecook1000/df70dd6a1e1aa1228d42
> 
> `unguardedRotate` is the method that would benefit from being locally scoped. It was even more fragile before the last refactor, but in its current form descends into an infinite loop if the parameter is either the startIndex or endIndex of the collection.

Thanks for sharing! Is there a reason to prefer `local` here over `private` or a slight refactor that embeds the unguarded logic in a nested function?

> For another example, see this comment in the standard library, which says not to use the _variantStorage property, then scroll down about twenty lines to see it used:
> 	https://github.com/apple/swift/blob/master/stdlib/public/core/HashedCollections.swift.gyb#L432
> 
> As a reader of this file, what should be my interpretation here? (a) The init that uses _variantStorage just got put in the wrong place, (b) the init should've been written without using _variantStorage, or (c) the comment is outdated? Marking _variantStorage as scoped and closing the initial declaration block of the type would both communicate and enforce the actual intent.


It also appears that `_variantStorage` is `internal` when it could be marked `private`, right?

A lot of this discussion brings me back to a point I brought up in my evaluation: if class/structure extensions could define storage from the same module in which they're defined, is there anything that `local` would provide that the existing model can't?

I do see `local` solving current problems and providing a more expressive/flexible ability to scope without having to reorganize things into multiple files and extensions, I just wonder if there are better solutions to the problems that don't require another level of access control.

Stephen