<div dir="ltr">I am ok with moving the public requirement for sealed-by-default. I have one qualm though. This would actually make starting out with the language a suboptimal experience. As (before, really) I teach what subclassing is, I have to explain this keyword to make subclassing possible. That sounds good until I realize that I should explain when you would want to add this keyword and I still haven't even gotten into what subclassing is yet. </div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 19, 2016 at 9:14 PM, Karl via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 17 Jul 2016, at 23:37, Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br>
><br>
>> On Jul 17, 2016, at 7:29 AM, Karl Wagner <<a href="mailto:razielim@gmail.com">razielim@gmail.com</a>> wrote:<br>
>><br>
>> Open and public are orthogonal concepts, just like final and public are today.<br>
><br>
> Are they? Given that "open" *means* "subclassable/overridable in public scope", what would it mean for something to be open, but not public? `final` *is* orthogonal, but I'm not sure `open` is.<br>
><br>
> --<br>
> Brent Royal-Gordon<br>
> Architechies<br>
><br>
<br>
<br>
Well that’s the point - we disagree on what “open” means. I don’t agree that the “in public scope” qualifier is necessary.<br>
<br>
Why are we doing this at all? Because we recognise that writing good base classes is hard.<br>
Why is writing good base classes hard? Because it’s difficult to locally reason about your code when members may be substituted by third parties.<br>
<br>
So what does this solution do? It explicitly annotates those members which may be substituted.<br>
<br>
This is a general problem - it doesn’t just affect publicly-accessible base classes, but also internal ones. It’s okay to be a bit sloppy with only-internally-open classes because you completely control every substitution, so you can fix any bugs later with an isolated library update. That is the only reason anybody could have for limiting “open” to public scope, as far as I’ve been able to tell — because it makes it easier to be sloppier.<br>
<br>
Still, I believe it would not do us any harm, and would actually do quite a bit of good (in light of the Swift API Design guidelines, which promote code which is easy to locally-reason about) if we applied this reasoning to all access scopes.<br>
<br>
That is to say, we basically introduce “open" as an inverted “final”, and make all classes non-open by default. That is analogous to enabling whole-module-optimisation by default, in my opinion. The cost of an extra four-letter word isn’t that great, but the benefits to readability and reasonability all-around make it worthwhile.<br>
<br>
Karl<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>