Ergonomics: generic types conforming "in more than one way"

[dabrahams (Dave Abrahams)]

@Nevin

Sure, if you can separate the example into a piece of free-standing code that I can download and run, I’d be happy to try it out.

Thanks. I don't know what I was seeing, but of course it doesn't reproduce anymore

[mattrips]

@Nevin

Inside an extension of Collection , such as your generic_distance method, only the witnesses for Collection methods are available, and in the case of DefaultIndices that means the default version of distance(from:to:) .

Sorry to resurrect this post, but I've been trying to reconcile the SR-12881 analysis, above, with the analysis of another protocol example here. In that other thread, we have a seemingly analogous situation:

• a protocol P (think Collection),
• a requirement of P called id (think distance(from:to:),
• a default implementation of that requirement declared in an extension of P (think Collection's default implementation of distance(from:to:)) ,
• a computed property in an extension of P called id2 that access id (think generic_distance(from:to:) and its call to distance(from:to:)),
• a protocol Q that refines P (think BidirectionalCollection's refinement of Collection),
• in an extension of Q, an implementation of the id requirement of P (think the distance(from:to:) implementation provided by BidirectionalCollection)

In the example from the other thread, within the id2 code, the access of id is able to be dispatched to the implementation provided by Q. But, here, the call to distance(from:to:) is not able to be dispatched to the implementation provided by BidirectionalCollection.

If I may impose on your time, what is the difference between the SR-12881 case and the example from the other thread such that the other-thread example gets the desired dispatch behavior but distance(from:to:) does not?