> On Mar 24, 2016, at 9:59 AM, Ilya Belenkiy <ilya.belen...@gmail.com> wrote: > > I am not sure if consistency is a problem here. My primary concern is that as > long as the class or extension code itself hasn't changed, it's private API > stays hidden from anything else. If we can simply inject a class into a class > or extension and get access to all of its internals, that reduces the > protection level that private would provide. I'd like private to hide > implementation details completely.
That wouldn’t be possible because the semantics are scope-based, not type-based. Here’s an example (using the new “private” modifier): fileA.swift: class C { private let s: String class Nested { func foo() { let c = C() // s is visible here because `Nested` and `foo` // are within the lexical scope that declared `s` let s = c.s } } } extension C { // `s` is not visible anywhere here // because we are not within the lexical scope // where `s` was declared } fileB.swift: extension C { // `s` is not visible anywhere here // because we are not within the lexical scope // where `s` was declared } > > That said, I am not sure if we need to discuss it as part of this proposal. > On Thu, Mar 24, 2016 at 10:28 AM Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: > > > Sent from my iPad > > On Mar 24, 2016, at 8:40 AM, Ilya Belenkiy <ilya.belen...@gmail.com > <mailto:ilya.belen...@gmail.com>> wrote: > >> The discussion was about the other direction: whether a nested class should >> have access to private members of the outer class. > > In that case the answer seems clear as well. Everywhere in Swift's access > model nested scopes have visibility to all members visible in the containing > scope. For example, all scopes in a file can see any "fileprivate" members > contained in that file. > > Following this semantic, all nested types would be able to see members of > their containing type, even those with the new "private" visibility because > the nested types are within the same scope where those members are declared. > > Semantic consistency is the most important concern IMO. All current access > modifiers are strictly based on nested scopes. Hiding members of a > containing type from a nested type would break this model and introduce > type-driven semantics, which I think (and hope) is beyond the scope of this > proposal (pun mildly intended). > > Matthew > >> >> On Thu, Mar 24, 2016 at 9:35 AM Matthew Johnson <matt...@anandabits.com >> <mailto:matt...@anandabits.com>> wrote: >> >> >> Sent from my iPad >> >> On Mar 24, 2016, at 5:07 AM, Ilya Belenkiy via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> It's very consistent with other keywords. I wish compound keywords were >>> joined with a dash or something that made them easier to read, but I guess >>> it's too late now. If we have associatedtype, it makes sense to use >>> moduleprivate (I saw that the name associatedtype was discussed >>> extensively but didn't participate in the discussion; I am sure that it was >>> given a lot of thought). If we could change this, I'd suggest keyword names >>> with dashes everywhere, but if not, these names work well and is a great >>> compromise for everything I've seen in this thread. >>> >>> I am not worried about the length because the 2 most frequently written >>> keywords would be public and private. Moduleprivate is the default, and >>> file private will not be used as often as private. >>> >>> One question: should the proposal be explicit about access control for >>> nested classes? We discussed it here briefly (I wanted private to be >>> completely private to the class or extension itself while 2 other people >>> wanted a nested class to have access to the outer class.) >> >> I don't think it would make sense at all to allow an outer type to see >> private members of a nested class. That would break the semantics of >> private meaning "containing scope". >> >> However, with Chris's suggestion of using identifiers as parameters, maybe >> we could eventually have something like private(OuterTypeName) to specify >> the precise level of access desired. >> >>> >>> On Thu, Mar 24, 2016 at 1:13 AM Chris Lattner via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> <responding to several posts in this thread at once> >>> >>> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> > Per Doug’s email, the core team agrees we should make a change here, but >>> > would like some bikeshedding to happen on the replacement name for >>> > private. >>> >>> What we do with private setters is orthogonal from this proposal, so I’m >>> going to ignore it in this thread. After SE-0025 is resolved, it would be >>> great to have another thread/proposal that discusses reskinning >>> private(set) - presumably as just a modifier on the setter. >>> >>> Similarly, this proposal has nothing to do with “protected” or any other >>> type based access control, so I don’t delve into that at all either. >>> >>> I’ve seen several proposals that seem promising: >>> >>> On Mar 14, 2016, at 5:49 PM, James Berry <jbe...@rogueorbit.com >>> <mailto:jbe...@rogueorbit.com>> wrote: >>> > I like fileprivate, if that’s the only change. On the other hand, if we >>> > want to consider a broader change, what about: >>> > >>> > private symbol visible within the current >>> > declaration (class, extension, etc). >>> > private(module) symbol visible within the current module. >>> > private(file) symbol visible within the current file. >>> >>> I love how this establishes a family with different levels of access >>> control, and unites them under the idea of "levels of being private”. I >>> also like how people would commonly only ever write public and private >>> (because “private(module)” is the default, and "private(file)" is obscure). >>> However, parenthesized modifiers that take a keyword (as opposed to an >>> identifier) are a bit weird and awkward, so it would be nice to avoid them >>> if possible. >>> >>> On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> > public >>> > private-module >>> > private-file >>> > private >>> >>> This follows the same sort of structure as James’ proposal, without the >>> parens. It has the same advantages, but trades them with hyphenated decl >>> modifiers. We don’t do that, but it is a good direction. >>> >>> 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> >>> _______________________________________________ >>> 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