Overloading relational operators separately; thoughts?

[Timon Gehr via Digitalmars-d]

On 28.09.2016 06:02, Walter Bright wrote:
> On 9/27/2016 6:18 PM, Minty Fresh wrote:
>> So, I'm just interested in other people's thoughts are on the subject,
>> and
>> whether there are any plans to allow overloading these operators
>> separately.
>
> The limitations are deliberate based on the idea that comparison
> operators need to be consistent and predictable, and should have a close
> relationship to the mathematical meaning of the operators. Overloading
> <= to mean something other than "less than or equal" is considered poor
> style in D, and the same goes for the other arithmetic operators.
> ...

The restrictions enforce that <= computes a boolean result. "less than 
or equal" is not necessarily the same as "decide /now/ whether this is 
less than or equal and give me a boolean". The restriction is annoying 
if you are implementing e.g. symbolic algebra. opCmp is a good thing to 
have for the common case, but why disable opBinary?


> The use of them to create DSLs (a technique called "expression
> templates" in C++) is discouraged in D, for several reasons. The
> recommended way to create DSLs in D is to parse strings using CTFE.

One anecdote: In the big-O library discussion, my initial proposal 
relied on string parsing. Andrei promptly criticized this and used 
operator overloading instead.

> An excellent example of that is the std.regex package.
> ...

It's actually a bad example, because it is irrelevant: it is obviously a 
bad idea to implement regex using operator overloading, because the 
regex operators have no D equivalent.

Assume I have two symbolic expressions a and b:

Expression a=variable("a"), b=variable("b");

Why should I be allowed to do

auto c = a + b; // symbolic value a + b

but not

auto d = a <= b; // symbolic value a <= b

The string parsing approach is not useful here: how do I use existing 
expressions that are accessible in the scope to build new expressions?