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

[Nate Cook]

> On Feb 26, 2016, at 9:42 PM, Stephen Celis <stephen.celis at gmail.com> wrote:
> 
>> On Feb 26, 2016, at 10:21 PM, Nate Cook via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> For example, one algorithm for rotating a collection uses an "unguarded" rotate as one of its steps, which is optimized to rotate a portion of the collection without bothering to check the inputs. It makes sense to extract this bit of the full rotation algorithm into a separate function, but it's unsafe to call unless very specific requirements are met that are unlikely outside the expected context. Being able to specify a local access level for the unguarded rotation would make this safer.
> 
> I'm curious if you could make the example more concrete and provide actual code that would benefit? One of the tough things about evaluating both SE-0025 and SE-0026 is that the proposals themselves contain very basic examples that don't sell the concepts.

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.

Nate