Overloading relational operators separately; thoughts?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, September 28, 2016 21:15:32 Walter Bright via Digitalmars-d 
wrote:
> Because then something other than comparison is happening with <=, <, >, >=
> and there'll be nothing in the code to give the user a hint.
[snip]
> D has many very powerful modeling abilities, but so far we've tried to stay
> away from things that make context-free user understanding of code unduly
> difficult. It should not be necessary to use an IDE to understand code.

A related issue is generic code. Having the same operator or function name
mean essentially the same thing for every type that has it is required for
generic code to work. To some extent, that's also checked by having the
semantics of the code checked (e.g. that front returns something as opposed
to being void or that popFront takes no arguments), but there's only so
much that can be done there. And no, even then, you can't guarantee that the
function in question operates the way that the generic code expects. But if
common function names mean the same thing and act the same way for types in
general, then they play well with generic code, whereas as soon as someone
takes a common function and makes it do something different from what's
normal, it does not play well with generic code at all.

Overloaded operators are the prime example of this, because there is a clear
expectation for what their basic behaviors are, and they're functions that
are built into the language. Next in line would be extremely common idioms
such as the range-based functions. Once you start getting to less common
stuff, then the issue of whether a function with a particular name acts the
same way in one library as another is significantly diminished, but for the
common stuff, it's critical for generic code that folks don't go and make
common functions operate in a way that is inconsistent with how they would
function on most every other type out there and how everyone is going to
expect them to behave when they see them.

Having a type implement something like expression templates is an utter
disaster for generic code, just like it's a disaster if front does something
like call popFront every time that it's called. Consistent semantics for
common functions is very important for generic code as well as for code
legibility and maintainability.

- Jonathan M Davis