<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 5:13 PM, Scott James Remnant &lt;<a href="mailto:scott@netsplit.com" class="">scott@netsplit.com</a>&gt; 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:47 PM, Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"></blockquote><blockquote type="cite" class=""><div class=""><div 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;" class="">This is not true. &nbsp;Public classes will *not* be “final by default”. &nbsp;It *will* be possible to subclass them within their declaring module. &nbsp;If they need to be final they will still need to be marked as such. &nbsp;</div><div 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;" class=""><br class=""></div></div></blockquote><div class=""><blockquote type="cite" class=""><div class="">With that in mind, the your “can override” column (do you really mean “can subclass” here?) is also not correct. &nbsp;The correct answer is “yes, within the module”. &nbsp;The fundamental difference for this row is that there are some scopes which can *see* the type without the ability to subclass it. &nbsp;There is no problem with this, it is *exactly* what we want. &nbsp;</div></blockquote><div class=""><div class=""><br class=""></div></div></div><div class="">So would this be more accurate?</div><div class=""><br class=""></div><div class=""><div class=""><font face="SFMono-Regular" class="">&nbsp; access &nbsp; &nbsp; &nbsp;| can access &nbsp; &nbsp;| can subclass/ &nbsp;| final</font></div><div class=""><font face="SFMono-Regular" class="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | override where |</font></div><div class=""><font face="SFMono-Regular" class="">&nbsp;-------------+</font><span style="font-family: SFMono-Regular;" class="">---------------+</span><span style="font-family: SFMono-Regular;" class="">----------------+-------</span></div><div class=""><font face="SFMono-Regular" class="">&nbsp;&nbsp;open &nbsp; &nbsp; &nbsp; &nbsp;| all scopes &nbsp; &nbsp;| all scopes &nbsp; &nbsp; | Error</font></div><div class=""><font face="SFMono-Regular" class="">&nbsp; public &nbsp; &nbsp; &nbsp;| all scopes &nbsp; &nbsp;| within module &nbsp;| final</font></div><div class=""><font face="SFMono-Regular" class="">&nbsp; internal &nbsp; &nbsp;| within module | within module &nbsp;| final</font></div><div class=""><font face="SFMono-Regular" class="">&nbsp; fileprivate | within file &nbsp; | within file &nbsp; &nbsp;| final</font></div><div class=""><font face="SFMono-Regular" class="">&nbsp; private &nbsp; &nbsp; | within scope &nbsp;| within scope &nbsp; | final</font></div></div></div></div></div></blockquote><div><br class=""></div><div>If you want to view “open” as an access modifier, then yes.</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=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><div 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;" class="">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="" 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;"></div></blockquote><div class=""><br class=""></div><div class="">I don’t have an issue with the purpose, I have an issue with doing it by conflating access control and finality, and making the language confusing as a result.</div></div></div></div></blockquote><div><br class=""></div><div>It’s not conflating access control and finality.</div><div><br class=""></div><div>It is also possible to view “open” and “sealed" as part of an “inheritability" hierarchy rather than the access control hierarchy.&nbsp;</div><div><br class=""></div><div>final &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;- never subclassable / overridable</div><div>sealed (default) &nbsp;- subclassable / overridable *within* the declaring module</div><div>open &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - always subclassable / overridable</div><div><br class=""></div><div>In some sense, “open” intersects access control and inheritability: &nbsp;it only makes sense on a public declarations and therefore implies public (whether we allow public to be inferred or not).</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=""><br class=""></div><div class="">Assuming the above table matches your expectation, compare it with the same matrix for the language as it is today:</div><div class=""><br class=""></div><div class=""><div class=""><font face="SFMono-Regular" class="">&nbsp; access &nbsp; &nbsp; &nbsp;| can access &nbsp; &nbsp;| can subclass/ &nbsp;| final</font></div><div class=""><font face="SFMono-Regular" class="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | override where |</font></div><div class=""><font face="SFMono-Regular" class="">&nbsp;-------------+</font><span style="font-family: SFMono-Regular;" class="">---------------+</span><span style="font-family: SFMono-Regular;" class="">----------------+-------</span></div><div class=""><span style="font-family: SFMono-Regular;" class="">&nbsp; public &nbsp; &nbsp; &nbsp;| all scopes &nbsp; &nbsp;| all scopes &nbsp; &nbsp; | final</span></div><div class=""><font face="SFMono-Regular" class="">&nbsp; internal &nbsp; &nbsp;| within module | within module &nbsp;| final</font></div><div class=""><font face="SFMono-Regular" class="">&nbsp; fileprivate | within file &nbsp; | within file &nbsp; &nbsp;| final</font></div><div class=""><font face="SFMono-Regular" class="">&nbsp; private &nbsp; &nbsp; | within scope &nbsp;| within scope &nbsp; | final</font></div><div class=""><br class=""></div></div><div class="">The existing table is clean, it’s easy to understand; the two concepts are entirely separate from each other. The access control keyword defines where a class, method, property, or subscript can be accessed from; the `final` keyword defines whether or not it can be subclassed or overridden.</div></div></div></div></blockquote><div><br class=""></div><div>Many of us believe “final” is too blunt a tool. &nbsp;There are many cases where final cannot be used but you still don’t want external users subclassing or overriding. &nbsp;</div><div><br class=""></div><div>We would like a more precise tool for these circumstances and believe if it is going to exist in Swift it should be the default. &nbsp;Its behavior follows the principle of requiring programmers to explicitly make decisions about what behavior is exposed outside of a module. &nbsp;You may not like that principle, but it is one that has been embraced by the language.</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=""><br class=""></div><div class=""><br class=""></div><div class="">To give you an example of the confusion, here is code made perfectly legal by SE-0025:</div><div class=""><br class=""></div><div class="">&nbsp; public final class Example {</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; overridable func foo() {}</div><div class=""><br class=""></div><div class="">&nbsp; }</div></div></div></div></blockquote><div><br class=""></div>I have no idea how you think this is related to SE-0025 (scoped access control). &nbsp;I also don’t understand why you think an `overridable` method in a `final` class would be legal under any proposal. &nbsp;That is nonsense and clearly in error.</div><div><br class=""></div><div>-Matthew</div><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=""><br class=""></div><div class="">Scott</div></div></div></div></blockquote></div><br class=""></body></html>