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 < [email protected]> wrote: > <responding to several posts in this thread at once> > > On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution < > [email protected]> 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 <[email protected]> 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 < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
