<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 <<a href="mailto:scott@netsplit.com" class="">scott@netsplit.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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 6, 2016, at 2:47 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> 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. 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 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. 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></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=""> access | can access | can subclass/ | final</font></div><div class=""><font face="SFMono-Regular" class=""> | | override where |</font></div><div class=""><font face="SFMono-Regular" class=""> -------------+</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=""> open | all scopes | all scopes | Error</font></div><div class=""><font face="SFMono-Regular" class=""> public | all scopes | within module | final</font></div><div class=""><font face="SFMono-Regular" class=""> internal | within module | within module | final</font></div><div class=""><font face="SFMono-Regular" class=""> fileprivate | within file | within file | final</font></div><div class=""><font face="SFMono-Regular" class=""> private | within scope | within scope | 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. </div><div><br class=""></div><div>final - never subclassable / overridable</div><div>sealed (default) - subclassable / overridable *within* the declaring module</div><div>open - always subclassable / overridable</div><div><br class=""></div><div>In some sense, “open” intersects access control and inheritability: 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=""> access | can access | can subclass/ | final</font></div><div class=""><font face="SFMono-Regular" class=""> | | override where |</font></div><div class=""><font face="SFMono-Regular" class=""> -------------+</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=""> public | all scopes | all scopes | final</span></div><div class=""><font face="SFMono-Regular" class=""> internal | within module | within module | final</font></div><div class=""><font face="SFMono-Regular" class=""> fileprivate | within file | within file | final</font></div><div class=""><font face="SFMono-Regular" class=""> private | within scope | within scope | 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. There are many cases where final cannot be used but you still don’t want external users subclassing or overriding. </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. Its behavior follows the principle of requiring programmers to explicitly make decisions about what behavior is exposed outside of a module. 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=""> public final class Example {</div><div class=""><br class=""></div><div class=""> overridable func foo() {}</div><div class=""><br class=""></div><div class=""> }</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). I also don’t understand why you think an `overridable` method in a `final` class would be legal under any proposal. 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>