The discussion was about the other direction: whether a nested class should have access to private members of the outer class.
On Thu, Mar 24, 2016 at 9:35 AM Matthew Johnson <[email protected]> wrote: > > > Sent from my iPad > > On Mar 24, 2016, at 5:07 AM, Ilya Belenkiy via swift-evolution < > [email protected]> wrote: > > 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.) > > > I don't think it would make sense at all to allow an outer type to see > private members of a nested class. That would break the semantics of > private meaning "containing scope". > > However, with Chris's suggestion of using identifiers as parameters, maybe > we could eventually have something like private(OuterTypeName) to specify > the precise level of access desired. > > > 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
