> The question then becomes simple: should a type gave the right to replace the > value in the protocol? Should protocol extensions therefore only be defaults? > > I would argue for treating the protocol as a default. If you had an identical > member in the type, use the type rather than the protocol extension. This > allows the most flexibility. That said, I am aware that means that some > optimisations are not possible. I simply think this makes the most sense from > a programming perspective.
I discuss this in the Alternatives section: > ### Dynamically dispatch calls to protocol extension members > > This would fix the underlying problem—the confusing behavior—by making > protocol extension members not behave confusingly. > > This would likely take a redesign of protocol witnesses to include extension > methods not listed in the original protocol. It's probably not > impossible—class extensions behave this way—but it's a much bigger change > than what I propose, which keeps the current runtime semantics and only adds > compile-time errors and keywords. > > Dynamically dispatching to protocol extension members would also change the > performance characteristics of these calls. Even if this change were made, we > might want to allow users to apply `final` to extension methods which they > want to be dispatched statically. Basically, I'm not proposing that simply because it's a larger change and would take redesigning that would have to wait until at least Swift 3, and is well beyond my own ability to specify or even evaluate the feasibility of. Plus, as I said in that last paragraph, `final` protocol extension members may be useful even if we do treat extension members as equivalent to defaulted protocol members. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
