<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Publishing a library is a promise of<span class="Apple-converted-space"> </span><i class="">something.</i> It ought to only be promises the library author <i class="">wants</i> to make. If “the truth” is “the implementation in the current version of the library”, that’s<span class="Apple-converted-space"> </span><i class="">definitely not</i> what a library author should promise. That’s true for plenty of things, not just whether or not overriding is expected.</div></div></blockquote></div>Correct, library users shouldn't have to puzzle over the authors intention, but I wasn't referring to source when I wrote about truth.<div class="">A good library should strive for flexibility, and don't impose restrictions that aren't necessary — "lack of extendability" imho is no promise an author should want to make.</div><div class="">So, what if he wants to promise extendability, but just isn't sure he will be able to stand by this promise? Instead of forcing him into lies, we could as well accept the reality of "I'm not sure", which imho would be the most reasonably default, as it doesn't pretend an explicit choice when there is only uncertainty.</div><div class=""><br class=""></div><div class="">Jonathan Hull outlined an alternative to 0117 (<a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/23761" class="">http://article.gmane.org/gmane.comp.lang.swift.evolution/23761</a>) which takes that into account — and imho has additional benefits:</div><div class="">- More power (for example, UIView.drawRect and other methods that shouldn't be called by clients could be modeled)</div><div class="">- Less confusion ("What's the point of subclassable and overridable? It has no effect on the ability to subclass and override in my app at all!")</div><div class=""><br class=""></div><div class="">Tino</div></body></html>