Just to clarify Karl, with your idea here, final wouldn't be necessary right? Since everything is already final by default?<br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 19, 2016 at 6:15 PM Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><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" target="_blank">brent@architechies.com</a>> wrote:<br>
><br>
>> On Jul 17, 2016, at 7:29 AM, Karl Wagner <<a href="mailto:razielim@gmail.com" target="_blank">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>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote></div>