<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="">On Jul 14, 2016, at 4:39 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">To sum this all up, the core team is … requesting a revision to change the concrete syntax to “public open class Foo” instead of “subclassable class Foo”.</div></div></div></blockquote><div><br class=""></div><div>Yes, +1 to “public open Foo” instead of “subclassable Foo”.</div><div><br class=""></div><div>Presumably “open” without “public” is an error…?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">[The core team] asks the community for an in-depth discussion of the secondary points of the proposal: does it make sense to require every member to be marked as “overridable” in order to be overridden by an open subclass outside of the current module?</div></div></div></blockquote><br class=""></div><div>Tentative +1 to this, though I’m open to hearing arguments otherwise.</div><div><br class=""></div><div>One could make a good case for overridable being the sensible default and require an explicit “final,” just as for internal subclassing. I lean against this for two reasons:</div><div><br class=""></div><div><ul class="MailOutline"><li class="">Explicit “overridable” is consistent with the general principle of explicit exposure of public promises in public APIs.</li><li class="">When a class is declared public, its members are still internal by default. By analogy, class-level “open” shouldn’t make members overridable by default either. With a language like Swift that encourages developers to lean on the compiler for verification, setting consistent expectations is crucial, and this behavior seems more consistent to me.</li></ul><div class=""><br class=""></div><div class="">I look at this proposal primarily from the point of view of a library author who is trying to design their API right, and is looking for assistance from the language in achieving that goal. The core team’s proposals seem consistent with this.</div><div class=""><br class=""></div><div class="">This makes me wonder whether we should remove member-level “final” from the language, and require “overridable” (i.e. final methods by default) even for members of non-open classes just for consistency and simplicity. That may be a separate proposal, but does seem like it needs consideration for Swift 3.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></div></div></body></html>