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

[Ilya Belenkiy]

I am not sure if we will ever get another access level. If we do, great,
but given how long this discussion has been already, I am not counting on
it :-)

Most likely, if we get more, it will be possible to describe it with a
simple word, or a combination of words or with some common abbreviations,
so I am not worried about extensibility. I think that the names in the
proposal are very consistent with Swift as it is today and will serve us
well. They are also completely unambiguous and don't depend on the reading
context, so if we come up with other ways to label access levels, it should
still be possible to either use these names for backward compatibility or
migrate them automatically to new names without any difference in semantics.

We also needed to pick something. I waited for about a week to get
everybody's vote, and I think that I picked a compromise that we can all be
at least ok with. (I also originally wanted short single word names). I
think we should close the naming thread at this point.
On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge <matthew.judge at gmail.com>
wrote:

>
>
> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> >> If Scala style access modifiers were adopted for Swift then a
> private(file) modifier would also be necessary to give the current private
> functionality.
> >
> > I could imagine having these options:
> >
> >    public                            // visible to all everyone
> >    private(scope-name, scope-name, …)    // visible to specified scopes
> (plus current scope)
> >    private                            // visible only to current scope
> >
>
> Allowing multiple "scope-name"s is a lot of flexibility and power, but not
> sure it's useful/worthwhile.
>
>  For the current discussion, I would think "scope-name" should be limited
> to an enclosing scope only.  So you can say "private(Outer)" from an Inner
> class or "private(#file)" from within a class, but not "private(ClassA)"
> from within ClassB.
>
> (This would also solve the ambiguity of how to reference the main ClassA
> or a specific extension to ClassA... "private(ClassA)" can only refer to
> whichever scope of ClassA you are currently in.)
>
> > scope-name could perhaps be:
> >
> > * A type name (or Self, which would mimic C++-style private, or perhaps
> even C++-style protected depending on how we treat inheritance)
>
> But, this is getting into type-based access which is beyond the scope of
> SE-0025 right?
>
> > * A module name (or #module for the current module)
> > * A file name string (or #file for the current file)
> >
> > And then the default would simply be `private(#module)`.
> >
> > Alternatively, the parameterized level could be given a different name,
> like `internal` or `shared`. If that were the case, then `#module` might
> simply be the default.
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > _______________________________________________
> > 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/20160330/012f628f/attachment.html>