[swift-evolution] Drafting a proposal: Make conflicting with protocol extension methods an error

[Dave Abrahams]

> On Dec 18, 2015, at 5:38 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> I’m not sure how it affects your proposal, but I just want to point out that having things that are *only* statically dispatched is sometimes desirable.  For example, Set equality is different from Collection equality, but Set conforms to Collection.  If you write an algorithm over equatable collections, it doesn’t know that the Collection happens to be a Set; it views the collection as a mere series of elements, and has a right to expect a == b to return true iff a[a.startIndex.advancedBy(n)] == b[b.startIndex.advancedBy(n)] for all n.  So the behavior of equality might be statically dispatched along this dimension.
> 
> I agree, and with this proposal you would still get static dispatch from a `final` protocol extension method. This proposal simply ensures that you can’t then implement an identical method in a conforming type, under the mistaken impression that the type-specific method will override the protocol extension.

That’s exactly what I think we want for Set (except for the “mistaken impression”) part.

> This proposal doesn’t actually change any calling semantics at all. It’s purely concerned with declarations: how they need to be keyworded to be more explicit, when a declaration might be forbidden in the presence of another declaration, and (if `@incoherent` is included) how you can disable that safety check when it’s getting in the way.

Maybe the only conclusion is that something like your @incoherent is needed, as opposed to being optional as the proposal suggests.

-Dave