<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="">-1<div class=""><br class=""></div><div class="">This proposal makes Swift a more confusing language.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Swift already has a mechanism for creating public subclassable classes and non-subclassable classes:</div><div class=""><br class=""></div><div class=""> public class SubclassableParentClass { }</div><div class=""><br class=""></div><div class=""> public final class NonSubclassableParentClass { }</div><div class=""><br class=""></div><div class="">This mechanism also applies to methods, properties, and subscripts:</div><div class=""><br class=""></div><div class=""> public func bar() {}</div><div class=""><br class=""></div><div class=""> public final func foo() {}</div><div class=""><br class=""></div><div class="">The proposal makes no effort to remove this existing syntax.</div><div class=""><br class=""></div><div class="">The very fact that this would be legitimate syntax as a result is a bad omen to me:</div><div class=""><div class=""><br class=""></div><div class=""> subclassable final class ConfusedParentClass {</div><div class=""><br class=""></div><div class=""> overridable final func quuz() {}</div><div class=""><br class=""></div><div class=""> }</div><div class=""><br class=""></div><div class="">The proposal doesn’t even address what that would do, the obvious answer is “compiler error,” but a better answer would be a language design that didn’t allow for this kind of ambiguity.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Conflating access control and finality is confusing. The proposal actually even goes as far to argue that—“conflates” is a word I took from the proposal—but it’s solution *is* a conflation in of its right, because the only way to explain the results is in terms of both:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">classes, methods, properties, and subscripts with access control of `internal`, `file private`, and `private` are overridable by code that can access them, to prevent this add the `final` keyword.</li><li class="">classes with access control of `public` are not overridable by code that can access them, to allow this replace the `public` keyword with the `subclassable` keyword.</li><li class="">methods, properties, and subscripts with access control of `public` are not overridable by code that can access them, to allow this replace the `public` keyword with the `overridable` keyword.</li></ul></div><div class=""><br class=""></div><div class="">Not only is this complicated, and confusing, it isn’t even consistent: to deny overriding or subclassing you add the same keyword; but to allow overriding or subclassing you replace one keyword with two different ones, depending on which you’re doing.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I agree that the alternative of flipping the default, and replacing `final` with `nonfinal` is also undesirable. One of the nicer features of the Swift language design is that the language is easiest for app developers working within a single module, where it can be assumed that “everyone is an adult.” Breaking this to support the less common case of Public API Designers would be a step backwards; their case is important, but it shouldn’t come at a penalty.</div><div class=""><br class=""></div><div class="">Scott</div></body></html>