[swift-evolution] Bridging the gap between protocols and protocol extensions

John McCall rjmccall at apple.com
Sun Jan 10 18:44:32 CST 2016


> On Jan 9, 2016, at 7:37 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> Forgive my ignorance if I am wrong, but without the objective-C runtime, we’re looking at dynamism from the perspective of vtables rather than from dynamic dispatch. I would assume the vtable approach would far closer approach vtable lookup than Dynamic dispatch. This appears to have no more overhead than standard protocols, and I would be very hazardous to call that “very slow dispatch”.
> 
> That's a large part of what I mean when I ask if it's feasible. Can the protocol witness vtables be made extensible in some way? If they can, and a dynamic protocol extension call is no slower than any other protocol member call, that's great. If they can't, and protocol extension methods need a slower form of dispatch or some kind of translation when crossing module boundaries, that's probably not acceptable.

If we make protocol extension methods dynamically dispatched (even as just an opt-in thing), we’d probably use a caching technique akin to objc_msgSend, keyed by the address of some global structure unique to the extension method.  This has the huge advantage of not requiring eager resolution of every extension method on every conformance, and it can still be made very fast — on the order of a few dozen cycles, i.e. maybe 50-75% slower than a v-table dispatch.  So it will not be as fast as a core requirement, but it’s likely to be close enough that all but the most performance-conscious programmers will be unaware of the difference, in the same way that most Java programmers have no need to be aware that dispatch through an interface type is usually slower than dispatch through a class type.

We would use a very similar approach for making out-of-module class extension methods dynamically dispatched.

John.

> 
> Class vtables can be extended in this way (and early in Swift's evolution, they even had overridability problems like protocol extensions now do), so I'm guessing it can be done. But protocols are in many ways more complicated than classes—particularly in their need to support multiple conformances rather than single inheritance—so I'm not willing to assume that it can be done without soliciting expert opinions.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list