>> My point is that "protected" *isn't* access control. If we added it, it >> would have to be as an independent modifier. Private/internal/public >> fundamentally affect semantics—private and internal code is only accessible >> within a module, so we have full knowledge of their use sites at compile >> time and can be more permissive with extensions, implicit constructors, and >> other features. Public API can be used by arbitrary unknown external code so >> requires additional restrictions to ensure that the interface remains >> stable. "Only usable by subclasses" is an orthogonal axis to this—if a >> method is only usable by external subclasses, it requires all of the same >> restrictions as public code. If a method is only usable by subclasses within >> the module, it can behave like a private or internal method.
Okay. So you see it as “public subclassonly”, leaving space for “internal subclassonly” (which makes sense, although not as important in practice). I can agree with that, let's consider it a new strawman. I wonder, though, if you guys have additional, fresh ideas on the underlying problem. We're not really limiting to subclasses here — we're limiting to “extenders” aka “service providers”, and those don't necessarily take a form of a subclass. I've listed some examples in my strawman: an implementation of a protocol, an extension of a class/protocol. Are there any novel and fresh ideas that would take care of all that in a straightforward and uncomplicated way? A.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
