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

[Chris Lattner]

On Mar 23, 2016, at 10:13 PM, Chris Lattner <clattner at apple.com> wrote:
> How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:
> 
> 	public
> 	moduleprivate
> 	fileprivate
> 	private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the submodule name/path in parens: private(foo.bar.baz) or moduleprivate(foo.bar).  Putting an identifier in the parens is much more natural than putting keywords in parens.

I’ve seen a number of concerns on this list about moduleprivate, and how it penalizes folks who want to explicitly write their access control.  I’ve come to think that there is yes-another possible path forward here (which I haven’t seen mentioned so far):

public
internal
fileprivate
private

The advantages, as I see them are:
1) We keep public and private meaning the “right” and “obvious” things.
2) The declmodifiers “read” correctly.
3) Compared to Swift 2, there is almost no change.  The only thing that changes is that some uses of Swift 2 “private” will be migrated to “fileprivate”, which makes the intent of the code much more clear.
4) fileprivate is the unusual and not-really-precedented-in-other-languages modifier, and it would still be “googable”.
5) The addresses the “excessively long” declmodifier problem that several people are concerned with.
6) Support for named submodules could be “dropped in” by parameterizing “internal”.

Thoughts?

-Chris