[swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Andrey Tarantsov]

> 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.)

A.