The last sentence was meant to be: Private and public have well defined meaning, we should keep the same semantics.
Still, this is an edge case. Maybe we can separate it into another proposal. On Thu, Mar 24, 2016 at 11:42 AM Ilya Belenkiy via swift-evolution < swift-evolution@swift.org> wrote: > This is why I'd like private to mean exactly that (no nested class should > get access). Then the meaning is clear: it's as private as it can be :-) > > Private and public have well defined meaning. We > On Thu, Mar 24, 2016 at 11:33 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
