Perhaps internal is valuable here then? Maybe: public, moduleinternal, fileinternal, private. Or just: public, internal, fileinternal, private. Or, more radically: public, internal, internal(#file), private.
On Thu, Mar 24, 2016 at 10:32 AM Ross O'Brien via swift-evolution < swift-evolution@swift.org> wrote: > I agree that 'private' still feels too subjective on its own. It's > intuitively 'not public'; it's not intuitively the access term for > 'declaration only'. > > I'm not opposed to fileprivate and moduleprivate, if we like those terms. > I'd just prefer a corresponding scopeprivate or declarationprivate. > > On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> > 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 >> >> I'm not sure my wording will be perfect here, but I will try: I still >> believe that private is implied in "module" and "file" and the problem is >> in the name of the plain "private" keyword. >> >> You may say private is obvious, but when you have moduleprivate and >> fileprivate, the natural question I ask is "What remaining kind of private >> is there?" so private's obviousness is muddied for me when next to >> moduleprivate and fileprivate. >> >> I will say I would prefer these keywords to the proposed parameter >> keywords. I just think: >> >> file -> implies file only >> module -> implies module only >> >> where adding private to them only adds noise (I.e. fileprivate and >> moduleprivate) >> >> Brandon >> _______________________________________________ >> 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution