On Wed, Jul 18, 2018 at 11:30:21AM -0600, Jonathan M Davis via Digitalmars-d wrote: > On Tuesday, July 17, 2018 21:18:12 John Colvin via Digitalmars-d wrote: > > Just do what std.typecons.Proxy does and return float.nan for the > > incomparable case. > > Since when is that legal? I thought that it was required for opCmp to > return int. Certainly, the spec implies that it has to be int. The > fact that the compiler allows it seems like a bug, though if Phobos is > doing it, it wouldn't surprise me if Walter would choose to update the > spec rather than fixing the compiler. [...]
Yeah, this is also a surprise to me. Is this a bug? I was under the impression that opCmp must return int. On the other hand, if opCmp is allowed to return a user-defined type, it would solve the problem in a neat way: just define a quaternary type that encapsulates the values -1, 0, 1, NaN, and have opCmp return the equivalent of NaN for non-comparable arguments. Then we could support partial orders correctly. But I have a hard time seeing this actually work in practice, because a user-defined return type for opCmp leads to recursion: in order to compare the return type against -1, 0, 1, etc., it would also need to implement opCmp itself. I'm almost certain this will cause the compiler to choke. :-D Not to mention opening up the possibility of ridiculous cases like having two user-defined types whose opCmp returns the other type, leading to infinite recursion. T -- Being able to learn is a great learning; being able to unlearn is a greater learning.