> 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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
