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.
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. Karl Sent from my new Email (https://itunes.apple.com/app/apple-store/id922793622?pt=814382&mt=8&ct=my_new_email) > > On Aug 15, 2016 at 9:50 am, <Jean-Daniel Dupas > (mailto:mail...@xenonium.com)> wrote: > > > > > > Le 14 août 2016 à 20:43, Karl via swift-evolution > > <swift-evolution@swift.org (mailto:swift-evolution@swift.org)> a écrit : > > > > > >> On 14 Aug 2016, at 11:17, John Holdsworth via swift-evolution > >> <swift-evolution@swift.org (mailto:swift-evolution@swift.org)> wrote: > >> > >> Hi folks, > >> > >> I see from building the latest Swift-3.0 branch that I’m a little behind > >> the times and this proposal has been accepted :( > >> > >> > >> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > >> > >> > >> Is there no way we can revisit this decision? 60 emails on a mail group > >> not read by the whole community > >> doesn’t quite seem enough validation for such a significant change to me. > >> Of those that expressed an > >> opinion on the thread many were against sealing classes outside the > >> module. > >> > >> > >> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022364.html > >> > >> > >> I personally feel it's a huge mistake for the following reasons: > >> > >> 1) it “breaks open source” reducing the reusability of third party > >> software by default. > >> > >> 2) Contrary to arguments about the likely performance benefits of > >> de-virtualisation of method dispatch it is > >> likely to make Swift programs launch more slowly due to the dynamic > >> linker having to slide large numbers > >> of function pointers for most method calls (itself an expensive > >> operation) whether a call is even made. > >> > >> On the first point it's an established technique in OOP to be able to > >> subclass and override to adapt a class > >> for a role perhaps it’s author never considered. Call this > >> “monkey-patching” if you like but it is a part of being > >> able to use open source libraries without having to make a fork as would > >> be the case if sealed by default. > >> Are we expecting developers to remember to leave their classes (and > >> methods?) "open”? If they do feel > >> that others shouldn’t subclass or override there was always “final". > >> Distinctions about whether this is possible > >> inside or outside a module seem a mute point to me. > >> > >> The second point is more of an engineering one. “Virtual” dispatch on > >> Swift is not a significant overhead > >> compared to fully dynamic dispatch on Objective-C which even then was > >> seldom a problem. There is a > >> cost however to de-virtualisation and resolving to a direct call to a > >> method address in that the dynamic > >> linker has to resolve and slide the pointer on load. This type of concern > >> is a bad argument to use in > >> designing a language anyway even if it is called Swift. > >> > >> 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 > >> most disagree with on evolution this far. Programmers have morals and > >> just because you shouldn’t > >> do something doesn’t mean the language needs to turn that into can’t by > >> default when the need arises. > >> If this change does go ahead please try to get it into the next Xcode > >> beta as it is a very incompatible one. > >> > >> Cheers, > >> > >> John > >> > >> > >> _______________________________________________ > >> swift-evolution mailing list > >> swift-evolution@swift.org (mailto:swift-evolution@swift.org) > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > > 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. > > > > 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. > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution