<div dir="ltr">On Tue, Feb 21, 2017 at 1:20 PM, David Waite via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Feb 21, 2017, at 3:47 AM, Joanna Carter via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
>> Le 21 févr. 2017 à 10:28, Slava Pestov <<a href="mailto:spestov@apple.com">spestov@apple.com</a>> a écrit :<br>
>><br>
>> There is one important difference, but it is rather obscure. ‘final’ allows a class to conform to protocols where ’Self’ appears in invariant position in requirements. For example, say you have the following:<br>
>><br>
>> …<br>
>> Also worth noting that removing ‘final’ from a class is going to be an ABI breaking change (and source compatibility too), whereas changing a ‘public’ class to ‘open’ poses no such difficulty.<br>
>><br>
>> I might be in favor of a proposal to just remove ‘final’ altogether, though, leaving us with just open and public. I’m not sure how much the ability for classes to conform to such protocols matters in practice.<br>
><br>
> I am not advocating removing 'final' from the language ; rather of removing 'open', which is "foreign" to anyone coming from any other language.<br>
<br>
</span>C# has a very similar concept of sealed members. In C++, members cannot be overrided unless they are declared virtual.<br>
<br>
C++ however lets you declare the same member in a subclass without it being used by superclass members or when invoked as the super type - this is mostly because code often don’t use polymorphism in C++ due to the performance and memory impact.<br></blockquote><div><br></div><div>Doesn't Kotlin have `open`? I believe it's used slightly differently, but from the perspective of a user of a third-party library I think the effect is the same in both languages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> My suggestion was to revert 'open' back to 'public' for visibility purposes and to use 'final' as the means of controlling inheritance/overriding that it has always been.<br>
<br>
</span>I’m not sure if you mean only controlling overridability at the type level, or defaulting to overridable. I can make strong counterarguments for retaining current behavior in both cases.<br>
<span class=""><br>
><br>
> IMO, it is 'open' that is superfluous to requirements.<br>
<br>
</span>Open is not about requirements. Open is about maintaining invariance of state and proper thread safety as required by the implementation of the superclass.<br>
<br>
If the goal isn’t to work within the bounds of a superclass implementation, protocols are a much more appropriate way to describe requirements<br>
<br>
-DW<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div>