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

[Rod Brown]

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”.

Protocol extensions that are final and not “default only" create 4 issues that I can see:

1. They lock a programmer into an implementation rather than an interface. This means if the implementations don’t perfectly match how you would perform the function (due to some internal state) then you must simply suffer and deal with it.

2. They create headaches for adhering to multiple protocols with the same method. This is currently being discussed on Swift Evolution as well.

3. They start to confuse what a protocol is - is it an implementation, or is it a guaranteed interface?

4. They seem to more closely model multiple inheritance, a model that was dismissed by the Swift team since Swift 1.0



> On 10 Jan 2016, at 12:17 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> I am not familiar with this so I can't comment specifically, but I would just like to mention that (with apologies to whoever might eventually have to implement this) the compiler is meant to serve the programmer, not the other way around.
> 
> Certainly, but the programmer will be ill-served if the compiler can only implement this with a very slow dispatch, or an expensive mandatory translation of protocol instances accessed across module lines, or with gaping semantic defects, or by dropping a dozen more-desirable features to implement it. And if it just can't be done, then it doesn't matter how well the compiler would serve the programmer by offering it.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution