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 < [email protected]> wrote: > > > > On Mar 24, 2016, at 01:13, 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. > > 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 < > [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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
