opCmp / opEquals do not actually support partial orders

[H. S. Teoh]

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.