<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:18 PM, Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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=""><br class=""><div class=""><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 class=""><br class=""></div><div class="">Yes, +1 to “public open Foo” instead of “subclassable Foo”.</div><div class=""><br class=""></div><div class="">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></div></div></div></blockquote><div><br class=""></div>I don’t see a reason for the openness/overridability/virtualness/finalness of a member to be more complex than a boolean. That is, while classes can be final, sealed or open, I believe members should only be “open” or “final”. I don’t see use cases to have members that are only overridable in-module but not by external parties. </div><div><br class=""></div><div>As we suspect an API designer to indicate whether a class is overridable or not by third parties and to determine whether members are exposed to third parties, I would expect them to also want to dictate *how* said type is overridable by third parties (e.g. which members are overridable). </div><div><br class=""></div><div>Whether we are open by default or final by default allows them to do this, but transitioning from final to open shouldn’t break existing API usage on revision. You won’t have someone accidentally using your library in a way you didn’t intend to support because you forgot to mark a method as ‘open’. Therefore, I lean toward final by default.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><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></div></blockquote><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""></div><div class="">In an inheritance chain, we have to decide whether a subclass inherits the method openness. If so, “final override” could still be valid. Otherwise, I agree about removing member-level ‘final'</div></div></div></div></div><div><br class=""></div><div>-DW</div><br class=""></body></html>