The access level discussed in the proposal already hides the members from nested types. The goal is to make something completely hidden outside of the scope. (otherwise, it would be possible to get access to something by simply inserting a nested class and without modifying the original class or extension definition). We discussed it during the review. So it is already the most private, and the name matches the meaning.
One of the goals of the core team in the response was to preserve the terms of art. In that sense, public and private make the most sense, the other two (internal and what today is called private) are not universal. > think moving `private` to this new access control level because it's the most private one we currently have sets a bad precedent. If we add a fifth level in Swift 4 (say, one that hides the member from nested types), does that now become `private` and we need to come up with a new name for the fourth level? Will users ever be able to get used to what the keywords actually mean? On Wed, Mar 16, 2016 at 7:01 PM Brent Royal-Gordon via swift-evolution < [email protected]> 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. > > > > To summarize the place we’d like to end up: > > > > - “public” -> symbol visible outside the current module. > > - “internal” -> symbol visible within the current module. > > - unknown -> symbol visible within the current file. > > - “private” -> symbol visible within the current declaration (class, > extension, etc). > > I think moving `private` to this new access control level because it's the > most private one we currently have sets a bad precedent. If we add a fifth > level in Swift 4 (say, one that hides the member from nested types), does > that now become `private` and we need to come up with a new name for the > fourth level? Will users ever be able to get used to what the keywords > actually mean? > > Rather than use relative terms, let's use absolute ones. An extreme, > imperfect example of what I mean: > > * exported > * module > * file > * scope > > Then if we add other access levels in the future, we don't have to worry > about reshuffling the existing names, because they will all still be > correct. We just have to come up with a good name for the new one. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > 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
