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

Andy Molloy amolloy at gmail.com
Sat Jan 9 16:52:59 CST 2016

> 1. Do people really want this?

Yes, if for no other reason than that the current behavior (imho) violates
the principle of least surprise - the surprising part being that the
behavior is different than other method calls. Further, there is no way to
know at the call site what the behavior is going to be, hindering

> 2. People familiar with the implementation of protocol witnesses: is this
> feasible?

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.

> 3. Do people want the current non-overridable, statically-dispatched
> protocol extension members available as an option?

Sure, why not? I would prefer it not be the default behavior, though. It
should be triggered by some keyword (final, default, etc) in the protocol

> 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?

I don't feel strongly one way or the other about this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160109/8cd4e9f8/attachment.html>

More information about the swift-evolution mailing list