[swift-evolution] Protected access level / multiple class/struct/protocol APIs
andrey at tarantsov.com
Tue Mar 29 05:54:31 CDT 2016
> Imho it would be nice to be able to mark a method that is only there to be overridden and should never be called directly, but I don't think the compiler has to enforce this:
> An official way to document the intent that affects autocompletion would be sufficient for me.
An interesting idea that I see reflected in another proposal (intendedusage doc tag, or something like that).
Why, though? If we can express it, why not also make it a part of the signature and get warnings/errors on violations?
I have an argument in favor of annotations:
+ The documentation is known to lie and to get out of date, even when acting on best intentions. I know mine did, and I'm writing a lot less of it now. So I also see compiler-enforced annotations as “more reliable documentation”.
What are other possible arguments for and against?
> - callable (read for properties)
> - can override, call to super enforced
> - can override
> - has to be overridden (abstract)
> - properties only: Write access
You're right, perhaps this isn't so much about access as it is about intended usage. (Not sure what that distinction means in practice, though.)
More information about the swift-evolution