> 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
