<html><body><div id="edo-message"><div>Yeah I know - that's why I said it would only work if we are okay with saying non-open != final, as a long-term decision. So the compiler won't devirtualize those calls.</div><div><br></div><div>As I understand it, that is how it works today - calls to non-open, non-final classes are still dynamically dispatched. There was a suggestion to make non-open == final, but that was expressly rejected.</div><div><br></div><div>Karl<br><br><div style="font-family: 'Helvetica Neue','Helvetica',Helvetica,Arial,sans-serif;font:'-apple-system-body';">Sent from my new <a href="https://itunes.apple.com/app/apple-store/id922793622?pt=814382&mt=8&ct=my_new_email">Email</a></div></div></div><div id="edo-original"><div><br><br><blockquote type="cite" style="margin:1ex 0 0 0;border-left:1px #ccc solid;padding-left:0.5ex;"><div>On Aug 15, 2016 at 9:50 am, <<a href="mailto:mailing@xenonium.com">Jean-Daniel Dupas</a>> wrote:<br><br></div><div><pre><br>> Le 14 août 2016 à 20:43, Karl via swift-evolution <<a dir="ltr" href="mailto:swift-evolution@swift.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="2">swift-evolution@swift.org</a>> a écrit :
<br>>
<br>>
<br>>> On 14 Aug 2016, at 11:17, John Holdsworth via swift-evolution <<a dir="ltr" href="mailto:swift-evolution@swift.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="4">swift-evolution@swift.org</a>> wrote:
<br>>>
<br>>> Hi folks,
<br>>>
<br>>> I see from building the latest Swift-3.0 branch that I’m a little behind the times and this proposal has been accepted :(
<br>>>
<br>>> <a dir="ltr" href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="5">https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md</a>
<br>>>
<br>>> Is there no way we can revisit this decision? 60 emails on a mail group not read by the whole community
<br>>> doesn’t quite seem enough validation for such a significant change to me. Of those that expressed an
<br>>> opinion on the thread many were against sealing classes outside the module.
<br>>>
<br>>> <a dir="ltr" href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022364.html" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="6">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022364.html</a>
<br>>>
<br>>> I personally feel it's a huge mistake for the following reasons:
<br>>>
<br>>> 1) it “breaks open source” reducing the reusability of third party software by default.
<br>>>
<br>>> 2) Contrary to arguments about the likely performance benefits of de-virtualisation of method dispatch it is
<br>>> likely to make Swift programs launch more slowly due to the dynamic linker having to slide large numbers
<br>>> of function pointers for most method calls (itself an expensive operation) whether a call is even made.
<br>>>
<br>>> On the first point it's an established technique in OOP to be able to subclass and override to adapt a class
<br>>> for a role perhaps it’s author never considered. Call this “monkey-patching” if you like but it is a part of being
<br>>> able to use open source libraries without having to make a fork as would be the case if sealed by default.
<br>>> Are we expecting developers to remember to leave their classes (and methods?) "open”? If they do feel
<br>>> that others shouldn’t subclass or override there was always “final". Distinctions about whether this is possible
<br>>> inside or outside a module seem a mute point to me.
<br>>>
<br>>> The second point is more of an engineering one. “Virtual” dispatch on Swift is not a significant overhead
<br>>> compared to fully dynamic dispatch on Objective-C which even then was seldom a problem. There is a
<br>>> cost however to de-virtualisation and resolving to a direct call to a method address in that the dynamic
<br>>> linker has to resolve and slide the pointer on load. This type of concern is a bad argument to use in
<br>>> designing a language anyway even if it is called Swift.
<br>>>
<br>>> Well, I know the boat has left on this one and I’ll likely have to live with it but this is the proposal I
<br>>> most disagree with on evolution this far. Programmers have morals and just because you shouldn’t
<br>>> do something doesn’t mean the language needs to turn that into can’t by default when the need arises.
<br>>> If this change does go ahead please try to get it into the next Xcode beta as it is a very incompatible one.
<br>>>
<br>>> Cheers,
<br>>>
<br>>> John
<br>>>
<br>>>
<br>>> _______________________________________________
<br>>> swift-evolution mailing list
<br>>> <a dir="ltr" href="mailto:swift-evolution@swift.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="7">swift-evolution@swift.org</a>
<br>>> <a dir="ltr" href="https://lists.swift.org/mailman/listinfo/swift-evolution" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="8">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
<br>>
<br>> It we are happy with non-open != final, I would be in favour of some kind of monkey-patching import attribute, similar to @testable, which allows you to subclass non-open classes at your own risk.
<br>>
<br>
<br>The non subclassable across module boundary is not just a compiler enforced limitation. Once you compile a module with classes that are ‘final’ in the module, the compiler may devirtualize all call sites in the module, or even inlining some calls, making subclassing unpredictable and pointless.
<br>
<br>
<br></pre></div></blockquote></div></div></body></html>