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

[Ilya Belenkiy]

this is more in line with other naming conventions, but the names in the
updated proposal seem to match the closest to everything else in Swift. I
waited for about a week to get everyone's opinion, but I think that we are
past the name discussions at this point.

On Sun, Mar 27, 2016 at 11:50 PM Matthew Judge via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> > On Mar 24, 2016, at 01:13, 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.
>
> If we borrow the "drop in" from below of private(foo.bar.baz), then maybe:
>
> private(#module) // expands to current module
> private(#file) // expands to current file
>
> This is slightly more awkward/one character longer, but now it's an
> identifier in parentheses (or something that expands to an identifier).
>
> I'm not sure I like this in practice unless it is fairly rare to actually
> have to type. If "private" at the top level of a file meant fileprivate (as
> I suggested in my other reply a few minutes ago) that would significantly
> reduce the need to type something other than just private.
>
> >
> >> 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
> _______________________________________________
> 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/20160328/d37f800f/attachment.html>