<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="">I almost sent out an email with what you wrote.&nbsp;</div><div class=""><br class=""></div><div class="">how about `public( nonfinal )`</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">- use “public(<u class="">nonfinal</u>)” to mean “exported out of the module, subclass/overridable”<br class=""></div></blockquote><div class=""><br class=""></div><div class="">I think just `open` would be a little bit better. `public( open )`</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jul 1, 2016, at 11:20 AM, Sean Heber via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Ok, I suppose that this design *basically* undoes the sealed by default thing, doesn’t it? :P &nbsp;lol. One of those days, I guess..<br class=""><br class="">Sigh.<br class=""><br class="">Crawling away…<br class=""><br class="">l8r<br class="">Sean<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jul 1, 2016, at 1:16 PM, Sean Heber &lt;<a href="mailto:sean@fifthace.com" class="">sean@fifthace.com</a>&gt; wrote:<br class=""><br class="">Coming in late on this, but here’s my take guided by the principal of least surprise (according to me):<br class=""><br class="">- everything is sealed within its module by default, no keyword<br class="">- use “public” to mean “exported out of the module, subclass/overridable”<br class="">- use “public(final)” to mean “exported out of the module, no subclassing or overriding externally, but overriding and subclasses allowed internally”<br class="">- meaning of “final” does not change<br class="">- using “public final” then means the same as both public(final) and also “final” internal to the module<br class="">- using “public(final) final” could be presented as an error with fixit since it’s redundant<br class=""><br class="">Did I miss anything?<br class=""><br class="">l8r<br class="">Sean<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jul 1, 2016, at 12:53 PM, John McCall via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""><blockquote type="cite" class="">On Jul 1, 2016, at 10:51 AM, Michael Ilseman &lt;<a href="mailto:milseman@apple.com" class="">milseman@apple.com</a>&gt; wrote:<br class="">If “opened”, who or what did the opening? If “open” is like “extensible”, then I would interpret “opened” to be like “extended”.<br class=""></blockquote><br class="">Yeah, I would prefer "open" to "opened".<br class=""><br class="">John.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On Jul 1, 2016, at 10:35 AM, Leonardo Pessoa via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class="">The proposal was to use "sealed" so why not "opened"? I understand it<br class="">may not be common to use "opened" as an adjective but from the<br class="">dictionaries I consulted it is possible to.<br class=""><br class="">opened class MyViewController: UIViewController {<br class=""> &nbsp;&nbsp;opened func displayMe(_ me: person) { … }<br class="">}<br class=""><br class="">On 1 July 2016 at 13:47, John McCall via swift-evolution<br class="">&lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><blockquote type="cite" class="">On Jul 1, 2016, at 12:23 AM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>&gt; wrote:<br class="">That starts to look an awful lot like a fifth access level just for classes<br class="">(I know you're not proposing one, but it could start to look that way to a<br class="">user). I think there's much to be said for having the word public in front<br class="">of things that are public. Unless, of course, your strawman keyword is a<br class="">much maligned compound word that begins with "public", like<br class="">"publicoverridable".<br class=""><br class=""><br class="">I would also prefer a single keyword if the word implies something about<br class="">accessibility. &nbsp;"open" does that, although using it here would conflict with<br class="">its potential use on enums unless we required all cases within the defining<br class="">module to be present in the enum declaration rather than extensions.<br class=""><br class="">I don't think we'd ever use a compound keyword that starts with public; we'd<br class="">just separate them and say that the second half can only be present on a<br class="">public declaration, or do this parenthesized syntax.<br class=""><br class="">John.<br class=""><br class=""><br class="">On Fri, Jul 1, 2016 at 01:54 Brent Royal-Gordon &lt;<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>&gt;<br class="">wrote:<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">If we're going to go along those lines, we should just use<br class="">public(subclassable) and public(overridable). &nbsp;We can fall back on those if<br class="">necessary; I would just like to continue looking for better alternatives.<br class=""></blockquote><br class="">I would prefer to have a *single* keyword which meant both public and<br class="">overridable. That would minimize the impact of this feature—instead of<br class="">writing:<br class=""><br class=""> &nbsp;&nbsp;&nbsp;public class MyViewController: UIViewController {<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;public func displayMe(_ me: person) { … }<br class=""> &nbsp;&nbsp;&nbsp;}<br class=""><br class="">You'd write (strawman keyword):<br class=""><br class=""> &nbsp;&nbsp;&nbsp;openseason class MyViewController: UIViewController {<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;openseason func displayMe(_ me: person) { … }<br class=""> &nbsp;&nbsp;&nbsp;}<br class=""><br class="">And then `MyViewController` could be subclassed, and `displayMe`<br class="">overridden.<br class=""><br class="">--<br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class=""></blockquote><br class=""><br class="">_______________________________________________<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=""><br class=""></blockquote>_______________________________________________<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=""></blockquote><br class=""></blockquote><br class="">_______________________________________________<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=""></blockquote><br class=""></blockquote><br class="">_______________________________________________<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></div></blockquote></div><br class=""></body></html>