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

[Brent Royal-Gordon]

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

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.

-- 
Brent Royal-Gordon
Architechies