<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 6, 2016, at 4:36 PM, Scott James Remnant 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 6, 2016, at 2:13 PM, Leonardo Pessoa <<a href="mailto:me@lmpessoa.com" class="">me@lmpessoa.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">You can also try and simplify your outlines reducing X.c and X.d to a<br class="">single entry as it is the same rule applied to two different elements<br class="">of the language. Using one single keyword (such as in 'open') would<br class="">make it clearer and that is why I prefer to have only one keyword.<br class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class=""><div class="">I didn’t simply the outlines precisely because the proposal suggests two keywords.</div><div class=""><br class=""></div><div class="">One keyword does solve this problem, but not the problem of conflation of finality and access control.</div><div class="">You end up with this matrix:</div><div class=""><br class=""></div><div class=""><font face="SFMono-Regular" class=""> access | can override | final</font></div><div class=""><font face="SFMono-Regular" class=""> -------------+--------------+-------</font></div><div class=""><font face="SFMono-Regular" class=""> open | yes | Error - “class cannot be open and final”</font></div></div></div></div></div></blockquote><div><br class=""></div><div>Of course this produces a compile error. Open means “can subclass” which directly contradicts final.</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=""><div class=""><div class=""><font face="SFMono-Regular" class=""> public | no | Error - “public class is already final by default”</font></div></div></div></div></div></blockquote><div><br class=""></div><div>This is not true. Public classes will *not* be “final by default”. It *will* be possible to subclass them within their declaring module. If they need to be final they will still need to be marked as such. </div><div><br class=""></div><div>With that in mind, the your “can override” column (do you really mean “can subclass” here?) is also not correct. The correct answer is “yes, within the module”. The fundamental difference for this row is that there are some scopes which can *see* the type without the ability to subclass it. There is no problem with this, it is *exactly* what we want. </div><div><br class=""></div><div>The purpose of this proposal is precisely to give library authors the ability to have more fine grained control over what capabilities their library exposes to users.</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=""><div class=""><div class=""><font face="SFMono-Regular" class=""> internal | yes | final</font></div><div class=""><font face="SFMono-Regular" class=""> fileprivate | yes | final</font></div><div class=""><font face="SFMono-Regular" class=""> private | yes | final</font></div><div class=""><br class=""></div><div class="">This is way more confusing than the current language:</div><div class=""><br class=""></div><div class=""><div class=""><font face="SFMono-Regular" class=""> access | can override | final</font></div><div class=""><font face="SFMono-Regular" class=""> -------------+--------------+-------</font></div><div class=""><span style="font-family: SFMono-Regular;" class=""> public | yes | final</span></div><div class=""><font face="SFMono-Regular" class=""> internal | yes | final</font></div><div class=""><font face="SFMono-Regular" class=""> fileprivate | yes | final</font></div><div class=""><font face="SFMono-Regular" class=""> private | yes | final</font></div><div class=""><br class=""></div><div class="">I strongly favor a programming language that doesn’t introduce compiler errors to solve problems that could be solved by cleaner syntax.</div><div class=""><br class=""></div><div class="">Since it’s already necessary to place the `public` keyword in front of every class, method, property, or subscript that you intend to make public, the developer is already thinking about the public API. Typing `public final` instead of `public` is an extra keyword, it’s not an extra cognitive burden since that cognition is already taking place.</div></div></div></div></div></div></blockquote><div><br class=""></div><div>As you can see from the points above, `public final` is something very different than both `public` and `public subclass able` (or `open`) under the current proposal. It is not a question of cleaner syntax. It is a question of whether we want to give library authors more fine grained control.</div><div><br class=""></div><div>-Matthew</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=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Scott</div></div></div></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>