<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=""><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 15 Jul 2016, at 12:46, Haravikk 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 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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>public(open)</div><div class=""><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 class=""><span class="Apple-tab-span" style="white-space:pre"> </span>public(final)</div><div class=""><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 class=""><span class="Apple-tab-span" style="white-space:pre"> </span>private(file)</div><div class=""><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 class=""><br class=""></div><div class="">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></div></div></div></blockquote></div><br class=""><div class="">I think it makes sense to have it bracketed, but I’m not sure about replacing internal/private/fileprivate.</div><div class=""><br class=""></div><div class="">I’m thinking it should be:</div><div class=""><br class=""></div><div class="">public(open) class XYZ {}</div><div class="">public internal(open) class XYZ {}</div><div class=""><br class=""></div><div class="">Etc</div><div class=""><br class=""></div><div class="">I view it along the same lines as mutability for properties - I.e. “public private(set)”.</div><div class=""><br class=""></div><div class="">In that case, it would make sense to do the same for overridable members. You can only override members of an open class, so it makes sense to just use the “open” name in both places to denote that you may create your own versions of these things. An overriden method “is” an instance of the original method in the same way a derived class “is” an instance of its base class. My overriden “viewDidLoad” or whatever “is” the viewDidLoad for this class.</div><div class=""><br class=""></div><div class="">So to summarise, I think it should look like this (just showing off features, obviously it wouldn’t be okay to have public(open) members in an internal(open) class...):</div><div class=""><br class=""></div><div class="">public internal(open) XYZ {</div><div class=""><br class=""></div><div class=""> public private(set) var nonOverridable : Something</div><div class=""> public(open) var overridable : Something</div><div class=""><br class=""></div><div class=""> public(open) private(set) var getterOverridable : UIColor? // In this case, the subclass can provide a value in its getter (e.g. backgroundColor) -</div><div class=""> // if it doesn’t (I.e. The type is optional), the base class may have a default value stored. I’m not sure… it’s an awkward one.</div><div class=""><br class=""></div><div class=""> public(open) func overridePointForSubclasses() {</div><div class=""> // Don’t you see so many functions named or documented like this? It’s nice that we’ll have them marked-up explicitly.</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">Karl</div></body></html>