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

[T.J. Usiyan]

+1

I think that what we have is completely workable but `local` could give an
added degree of control and expression while preserving/augmenting the
model that we already have for access modifiers.

On Sun, Feb 28, 2016 at 2:18 AM, Nate Cook via swift-evolution <
swift-evolution at swift.org> wrote:

> > 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
>
>
> _______________________________________________
> 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/20160228/82387e48/attachment.html>