[swift-evolution] Bridging the gap between protocols and protocol extensions
David Waite
david at alkaline-solutions.com
Sat Jan 9 17:02:58 CST 2016
> On Jan 9, 2016, at 3:05 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>
> From my previous thread, "[Draft Proposal] Require `final` on protocol extension members", I'm getting the sense that many people want straight-up dynamic dispatch from protocol extension methods. That is, protocol extension methods should be treated as if they were included as requirements of the protocol; the implementations provided should be treated as overridable defaults.
>
> A few questions about that:
>
> 1. Do people really want this?
I can’t speak for all people, but I don’t.
Protocol extensions which are not part of the protocol are not part of any explicit contract, and are not ‘opted into’ by the implementing types. Code in protocol extensions will break if they have interdependent methods which change behavior because I implemented a method with the same name but different behavior.
> 2. People familiar with the implementation of protocol witnesses: is this feasible?
>
> 3. Do people want the current non-overridable, statically-dispatched protocol extension members available as an option?
Yes.
> 4. Should this be proposed alongside other changes that would reduce the difference between a protocol and a protocol extension, like allowing default implementations in the protocol declaration?
Having default implementations inside the protocol would help illustrate a default implementation is available. Currently, it can be confusing what you do or do not need to implement in order to conform to a protocol.
-DW
More information about the swift-evolution
mailing list