[swift-evolution] [Draft Proposal] Require `final` on protocol extension members

[Goffredo Marocchi]

I agree with you, if we tackle this and we should then we should aim to the right solution if it is reachable. 
I know I am in the minority and it is partially off topic here, but I do feel that default method implementations are something that might be put to good use, but it is best to try to make sure no unintentional side effects are produced too easily. In a way you give out a possibly dangerous tool, you have protocols and you pass around objects referenced not by the actual type but by the protocol it is represented by to make sure that the receiver cannot make any assumption on the actual implementation beyond the abstract API contract and default methods do expose that. 

Sent from my iPhone

> On 5 Jan 2016, at 00:11, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Sorry Brent, I obviously didn’t read down to the alternatives section. Stupid me.
> 
> I think that it is a larger change, but if we’re going to change this, shouldn’t we do it right?
> 
> From my perspective, a protocol says what “should” happen, whereas a type is where it eventually “does” happen. I find it a little backwards to make protocol extensions mandatorily final. It blocks out the power of defaulting.  I definitely agree with you that final in protocol extensions is a great idea, though.
> 
> 
>>> On 5 Jan 2016, at 10:13 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
>>> 
>>> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution