<div dir="ltr">I tend to think an intended use annotation that could also be used in Obj-C would be better than protected. The problem with protected is that it provides virtually no protection at all; you can trivially expose it in a derived class, e.g.:<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>class Protected {</div></blockquote></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">protected func onlyDerived() { ... }<br></blockquote></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">}<br><br>class Derived: Protected {<br></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">public override func onlyDerived() { super.onlyDerived() }</blockquote></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">}<br><br>let d = Derived()<br>d.onlyDerived() // Protection lost<br><br></blockquote>Therefore an annotation would be just as effective.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 29 March 2016 at 21:54, Andrey Tarantsov via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> 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:<br>
> An official way to document the intent that affects autocompletion would be sufficient for me.<br>
<br>
</span>An interesting idea that I see reflected in another proposal (intendedusage doc tag, or something like that).<br>
<br>
Why, though? If we can express it, why not also make it a part of the signature and get warnings/errors on violations?<br>
<br>
I have an argument in favor of annotations:<br>
<br>
+ 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”.<br>
<br>
What are other possible arguments for and against?<br>
<span class=""><br>
> - callable (read for properties)<br>
> - can override, call to super enforced<br>
> - can override<br>
> - has to be overridden (abstract)<br>
> - properties only: Write access<br>
<br>
</span>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.)<br>
<span class="HOEnZb"><font color="#888888"><br>
A.<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>