> On Mar 24, 2016, at 10:52 AM, Ilya Belenkiy via swift-evolution > <swift-evolution@swift.org> wrote: > > 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.
I think any change in semantics should absolutely be a separate proposal. I support scope-based access semantics. My opinion about other access semantics would depend on the details of a specific proposal, but I think there is a very high hurdle to clear for introducing any other access semantics. > > On Thu, Mar 24, 2016 at 11:42 AM Ilya Belenkiy via swift-evolution > <swift-evolution@swift.org <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <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 <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
