<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 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><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="">To sum this all up, the core team is rejecting this proposal and requesting a revision to change the concrete syntax to “public open class Foo” instead of “subclassable class Foo". </div></div></div></div></blockquote><div><br class=""></div><div>Minor point, but if we're going with the idea of public open and public final for declaration, is it worth re-raising the idea of bracketed accessibility modifiers? When fileprivate vs private was being discussed I was heavily in favour of private(file), private(scope) and private(module) (plus private(type) if we get that) to avoid polluting the language with more accessibility-specific keywords. This seems like a good time to mention it again, as we're now looking at even more keyword pollution:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>public(open)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>public(sealed)<span class="Apple-tab-span" style="white-space:pre"> </span>// Probably not actually defined, but the default for a plain "public" declaration</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>public(final)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>private(module)<span class="Apple-tab-span" style="white-space:pre"> </span>// Replaces internal</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>private(file)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>private(scope)<span class="Apple-tab-span" style="white-space:pre"> </span>// Default for plain private</div><div><br class=""></div><div>If we get a private(type) that's seven different keyword combinations for one feature, so I still very much prefer it being reduced to just public/private plus a modifier ;)</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="">This approach satisfies the *<b class="">unwavering</b>* goal of requiring additional thought when publishing a class as public API, makes subclass-ability orthogonal to access control, and (admittedly as a bit of a swift-evolution process hack) 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></div></blockquote><div><br class=""></div><div>Personally I'm fine with the proposal's original intent; public open gives a clear guarantee that overriding is okay, while plain public produces a warning encouraging developers to contact an API author if they choose to sub-class it anyway, as it may be unsafe. This lets them leave things nominally open, and address only the parts of their API that people actually want to sub-class, after all, predicting every possible use-case is a non-trivial challenge, and I think it's unreasonable to expect it of everyone.</div><div><br class=""></div><div>That said, linters should probably highlight public declarations that lack open or final; if Xcode had a less obtrusive, purely informational, "problem" type then I'd recommend that but that's a separate issue I think.</div><div><br class=""></div><div>But yeah, I think it's important to avoid trying to force public open or public final only, as that could lead to bad habits with developers just defining whichever they feel is easiest, probably leading to loads of types that end up being final by default. Better IMO to let developers to define things the easy way first, then go back and decide what exactly needs to be sub-classable once any implementation issues have been resolved.</div></div></body></html>