> On Mar 24, 2016, at 01:13, 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.
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@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
