no, I still want extensions to be able to hide their implementation details from anything else (including other extensions of the same type or the "root" class definition). And I also want to be able to hide stuff in the root class definition from extensions of the same type. I just don't want an ability to inject new class in a scope to get access to its implementation details.
That said, I will not include it in the updated proposal (i'll only update the names) and will start a new thread after SE-0025. Also, I think that it's an edge case, and it could be argued either way. On Thu, Mar 24, 2016 at 11:47 AM Matthew Johnson <[email protected]> wrote: > 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]> 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]> 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] >>> > 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] >>> 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
