> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
