[swift-evolution] Protected access level / multiple class/struct/protocol APIs
andrey at tarantsov.com
Sun Apr 3 11:44:03 CDT 2016
>> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution