Ok, I guess I never used nested types much in C++. If this is standard, I don't want to change it. I'll revert back to the pure "scoped" meaning. Thank you, this was very useful.
On Mon, Mar 28, 2016 at 4:30 PM Jordan Rose <[email protected]> wrote: > On Mar 28, 2016, at 11:40, Ilya Belenkiy <[email protected]> wrote: > > > I *still* don't understand your reasoning here. If a private member can > be used in a member function, and in closures inside that member function, > why can't it be used in a member type? > > The simplest answer is that it's the most private access level, and also > one that doesn't create any confusion. We already discussed several times > here whether inner should have access to outer or the other way around. > With this design, the answer is neither. > > A longer answer is that if you move a function into a type and make it a > member function, you change the semantics. It's no longer the same > function. If you move the type inside another type, the semantics is the > same. The only difference is that we get shorter names. Also, if you move a > function to be a member function, that changes the class API. If you move a > class to become a nested class, that does not change the outer class API. > Both classes can be used the same way but with different spelling of the > name of the inner class. > > Also, I think that the terminology of access level really comes from OOP. > The problem with the current state of things is that it mixes this > terminology with export levels. This proposal makes "private" mean what it > means in OOP and extends it so that it makes sense with Swift extensions. > > If we were talking about "scoped" level access, the immediate scope > addition would be wrong. But if we are talking about "private", it's a > different matter. > > > I don't buy this argument. Before Swift, there have been plenty of OO > languages with extensions and plenty with access control, but no major ones > with both except Ruby (discounting Objective-C's @private instance > variables). And, ignoring extensions, the behavior of 'private' in all of > these languages is to include access from member types: > > - C++: yes > - Java: yes > - C#: yes > > - Ruby: no, but even the outer class can't invoke private methods on a > different instance of itself > - D: yes, but D's "private" is closer to Swift's current "private" than > anything else > > - Kotlin: yes > - Scala, Python, Go, Rust, Objective-C, Smalltalk: either no access > control or no nested types, AFAICT > > So "private" in these languages doesn't seem to mean "restricted to this > type", and that shouldn't be considered the "obvious" meaning when several > of us have considered it decidedly non-obvious. > > Best, > Jordan > > P.S. "If you move the type inside another type, the semantics is the > same." This already isn't true if the new member type is used to satisfy a > protocol requirement (which, because of retroactive modeling, counts as > "changing the class's API"), but it especially won't be true if/when we > start allowing member types inside generic types. In that case, the inner > type now has extra generic parameterization that it wouldn't have had > before. > > P.S. Extensions do make things a little more complicated, but again, > there's almost no precedent here, and pretty much everyone agrees that this > new scope-private access level shouldn't give access to extensions. That > also means there's an option to keep yourself from accidentally accessing > scope-private members in a member type: put the member type in an extension. >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
