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.
