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

[Ilya Belenkiy]

With these names we lose consistency. The current scheme makes it very
clear that each next level is a subset of the previous level. With
"internal", fileprivate looks out of place.

We have several goals for all the names:
1) obvious
2) using standard terms
3) short
4) consistent

This discussion shows that we cannot have all of them. We have to pick
something at the expense of something else.

For me, the order of importance is 2, 4, 1, 3, and I am pretty sure that
with this order

public
moduleprivate
fileprivate
private

is the best so far.

public
internal
fileprivate
private

is not as consistent. It's also not as obvious, given that many people
proposed to use internal to mean fileprivate. The biggest advantages of
these names are that there is less change and short words. If these are the
most important goals, then my original proposal is even better:

public
internal
private
scoped

It's a non-breaking change, everything retains its meaning, the added name
is very clear, and all the names are very short. The biggest problem here
is "private" -- it's not the most private that the language provides, and
most people would expect that.

Here is another one like that (it solves the "private" problem at the
expense of using non-standard terms):

public
internal
local
scoped

My main point is that we cannot have everything. We have to pick the order
of importance.

We heard many times that "short" is not the goal of Swift. Instead, it's
clarity. If this is the case, then I think

public
moduleprivate
fileprivate
private

is the clearest we've seen. Nobody could possibly be confused about the
meaning of these names. I doubt that moduleprivate will be required to
spell out in any style guide, but even so, it's not so bad. We have many
frequently used class names that are much longer.

On Thu, Mar 31, 2016 at 12:22 AM Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
> _______________________________________________
> 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/20160401/114092c4/attachment.html>