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

[Ilya Belenkiy]

It's very consistent with other keywords. I wish compound keywords were
joined with a dash or something that made them easier to read, but I guess
it's too late now. If we have associatedtype, it makes sense to use
moduleprivate (I saw that the name associatedtype was discussed extensively
but didn't participate in the discussion; I am sure that it was given a lot
of thought). If we could change this, I'd suggest keyword names with dashes
everywhere, but if not, these names work well and is a great compromise for
everything I've seen in this thread.

I am not worried about the length because the 2 most frequently written
keywords would be public and private. Moduleprivate is the default, and
file private will not be used as often as private.

One question: should the proposal be explicit about access control for
nested classes? We discussed it here briefly (I wanted private to be
completely private to the class or extension itself while 2 other people
wanted a nested class to have access to the outer class.)

On Thu, Mar 24, 2016 at 1:13 AM Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> <responding to several posts in this thread at once>
>
> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> > Per Doug’s email, the core team agrees we should make a change here, but
> would like some bikeshedding to happen on the replacement name for private.
>
> What we do with private setters is orthogonal from this proposal, so I’m
> going to ignore it in this thread.  After SE-0025 is resolved, it would be
> great to have another thread/proposal that discusses reskinning
> private(set) - presumably as just a modifier on the setter.
>
> Similarly, this proposal has nothing to do with “protected” or any other
> type based access control, so I don’t delve into that at all either.
>
> I’ve seen several proposals that seem promising:
>
> On Mar 14, 2016, at 5:49 PM, James Berry <jberry at rogueorbit.com> wrote:
> > I like fileprivate, if that’s the only change. On the other hand, if we
> want to consider a broader change, what about:
> >
> >       private                 symbol visible within the current
> declaration (class, extension, etc).
> >       private(module) symbol visible within the current module.
> >       private(file)           symbol visible within the current file.
>
> I love how this establishes a family with different levels of access
> control, and unites them under the idea of "levels of being private”.  I
> also like how people would commonly only ever write public and private
> (because “private(module)” is the default, and "private(file)" is
> obscure).  However, parenthesized modifiers that take a keyword (as opposed
> to an identifier) are a bit weird and awkward, so it would be nice to avoid
> them if possible.
>
> On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution <
> swift-evolution at swift.org> wrote:
> > public
> > private-module
> > private-file
> > private
>
> This follows the same sort of structure as James’ proposal, without the
> parens.  It has the same advantages, but trades them with hyphenated decl
> modifiers.  We don’t do that, but it is a good direction.
>
> 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.
>
> What do you all think?
>
> -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/20160324/95e96fee/attachment.html>