> On Mar 24, 2016, at 10:40 AM, Ilya Belenkiy via swift-evolution > <[email protected]> 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 :-)
In that case, you want a type-based access control mechanism, not a scope-based access control mechanism. Your proposal that was provisionally accepted is for a scope-based mechanism. Chris’s request for bikeshedding on names did not include a request to bikeshed on semantics. Any discussion about type-based access control should happen in a different thread IMO. > > Private and public have well defined meaning. We > On Thu, Mar 24, 2016 at 11:33 AM Ross O'Brien via swift-evolution > <[email protected] <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> 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 > > [email protected] <mailto:[email protected]> > > 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 > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
