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?
