Hi Matt,
AFAICT this code is almost the same as my earlier example. My id2 (which corresponds to callID in your example) would be on an extension of Q rather than of P. So your example effectively points out that the P requirement id is satisfied the same way for the X<T>:P witness table as for the X<T>:Q witness table. I find that mostly unsurprising given the (always re-surprising!) fact that X<T> can only conform to P “in one way.” It's also nearly the same as your earlier example except in that example your P requirement a() (which corresponds to id) is being accessed through a different P requirement b(), rather than a non-requirement (callId/id2).
Also, all of these semantics seem consistent with what @Jens pointed out about the original proposals: we were warned. It's only since I realized this had serious negative consequences for generic programming that I've started hearing @Douglas_Gregor suggest that it could be changed. However, there are two very open questions still, AFAICT:
- Is Doug actually talking about the same things we are? So far his description has been in very implementation-centric terms that don't map clearly onto a programming model.
- Can we change the language semantics and call it a bug fix, even if the language implements exactly or nearly what was proposed and accepted?
Surely WWDC pressure explains why we don't have answers yet; I look forward to Doug's re-engagement after the conference is over.