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

[Rod Brown]

Please see my response inline.

-Rod


> On 10 Jan 2016, at 9:05 AM, 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?
Yes. I think it makes the most sense. While I appreciate the optimisation, I think the idea of protocols forcing an implementation on the type is backwards, and potentially dangerous when the protocol has no understanding of the potential repercussions on how the implementing type is implemented.

> 
> 2. People familiar with the implementation of protocol witnesses: is this feasible?
Unfortunately I have no experience here.

> 
> 3. Do people want the current non-overridable, statically-dispatched protocol extension members available as an option?
I think there might be a use case, but I debate the safety and usability of a protocol as such. When you’re implementing the protocol, as has been discussed above, you cannot be aware of all the ramifications of your code on another potential type. Whilst a “non-overridable, final” implementation would be be better for inlining, I question whether the benefit is worth the risks.

> 
> 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?
It appears like it should go through at a similar time frame, if not together. They are all consistent with a streamlining of the protocol/protocol extension design. How that is implemented in proposals, would be best left to the Core Swift Team’s guidance.

> 
> 5. Especially with #3 or #4, this sounds like a very large change which could be broken up into several smaller ones. Core team members: what is the best way to propose this? One big proposal with all the details, several small proposals, or a big vague proposal for the overall direction, followed by several smaller proposals with a detailed design for each part?
N/A as I am not a core team member.

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution