Thanks, Chris, for summing up and pulling this back together. I’m +1 on your suggestion of public, moduleprivate, fileprivate, and private. I share your feeling of slight awkwardness about the parens in my previous suggestion.
As to other’s expressed concerns about smashedlowerkeywords, they don’t bother me too much. I prefer consistency here. As an alternative I’d find lower_snake_case acceptable, but would like to see it applied consistently, and thus also to associatedtype, etc. I don’t like lowerCamelCase for keywords. But if I had my druthers it would be to maintain the status quo of smashedlower. James > On Mar 23, 2016, at 10:13 PM, Chris Lattner via swift-evolution > <swift-evolution@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@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 <jbe...@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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
