> On Dec 18, 2015, at 5:38 PM, Brent Royal-Gordon <[email protected]> > 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
