[swift-evolution] SE-0025: Scoped Access Level, next steps

[Jordan Rose]

> On Mar 29, 2016, at 10:14 , David Owens II <david at owensd.io> wrote:
> 
>> Additionally, we think we can get away with renaming "private" because most current uses of "private" (file-scoped) declarations are within the same (brace-bound) scope anyway;
> 
> A quick look through my code bases verifies that this is true with my small sample of code. The only outliers are private members on types accessed by extensions, but those are fairly rare in my use cases, and arguably, those should be changed to internal. Maybe that varies for others.
> 
> Honestly, if the assertion is already that most of the current private use cases are for lexically scoped uses anyway, is it really worth trying to add a file-based private as well that essentially pops out of the lexical scope only up to the file level? For those use cases, just use `internal`. Using `private` would still be available for top-level declarations on the file.
> 
> We would end up with just this:
> 
> `public` - publicly exported for use by all code that uses the library
> `internal` - only allowed for use within the current module
> `private` - the new, lexically scoped modifier
> 
> If file-based is really required for a small set of cases, use `private internal`.

A good handful of people already enumerated several cases where file-based scoping is useful, and I very much agree. Leaking helper operations across an entire module just because they can't be lexically scoped, or don't make sense to, doesn't seem like a good answer to me.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160329/699ee14b/attachment.html>