opCmp, [partial/total/pre]orders, custom floating point types etc.

[John Colvin via Digitalmars-d]

On Tuesday, 12 January 2016 at 21:12:08 UTC, tsbockman wrote:
> On Tuesday, 12 January 2016 at 20:56:41 UTC, John Colvin wrote:
>> Please consider the second design I proposed? It's small, 
>> simple, has no impact on existing code and works in the right 
>> direction (library types can emulate / act as replacements for 
>> builtins) as opposed to the other way (library types are 
>> second class).
>
> If non-total ordering is going to be supported, I don't 
> understand what's wrong with just allowing this:
>
>     bool opCmp(string op, T)(T right) const { }
>
> As an alternative to the current:
>
>     bool opEquals(T)(T right) const { }
>     int opCmp(T)(T right) const { }
>
> Make it a compile-time error for a type to implement both. 
> There is no need to deprecate the current system - people can 
> even be encouraged to continue using it, in the very common 
> case where it can actually express the desired logic.
>
> This approach is simple and breaks no existing code. It is also 
> optimally efficient with respect to runtime performance.

I would kindof like that (it would definitely allow me to do what 
I want, as well as anything else I have failed to notice I need 
yet), but it flies quite strongly against Walter's (and mine to 
some extent) views that we'll only end up with C++-like abuse of 
the overloading if we allow that. Having > and < overloaded 
separately is asking for trouble.

Another possibility would be to introduce opCmpEquals(T)(T rhs) 
to handle [<>]= explicitly.