Overloading relational operators separately; thoughts?

[Minty Fresh via Digitalmars-d]

On Wednesday, 28 September 2016 at 03:12:05 UTC, Jonathan M Davis 
wrote:
> On Wednesday, September 28, 2016 01:18:58 Minty Fresh via 
> Digitalmars-d wrote:
> Basically, having them be overloaded separately is error-prone, 
> and it leads to folks overloading them in ways that have 
> nothing to do with what they mean for the built-in types, which 
> makes code harder to read and maintain. D has a concatenation 
> operator specifically because Walter thought that it was 
> horrible to use + for concatenation.
>
> If you want to write DSLs, then use strings and mixins. D gives 
> you a _lot_ of power in that area, and it avoids the problems 
> associated with making overloaded operators do things other 
> than what those operators are normally intended to do. With 
> strings, you can make your DSL look however you want - even 
> doing stuff like using various Unicode symbols as operators if 
> you want to. Even with how C++ overloads operators, overloading 
> operators gives you fairly limited options with what you can do 
> with a DSL, whereas you have full freedom with strings - and 
> without the problems that come with trying to make your DSL 
> look like normal D code.
>
> - Jonathan M Davis

Using strings and mixins does have quite a number of downsides. 
The additional work required to past the DSL aside, you also 
usually lose the scope in which things are declared (especially 
if you wish to reference or declare variables/functions/other 
constructs within your DSL), error reporting becomes much less 
precise, and the transition between the outer code and the inner 
DSL becomes jarring (especially in terms of syntax highlighting).

That said, I love the fact D has a separate operator for 
concatenation. It's extremely useful to not have that ambiguity.

Another thought is, operators not behaving as expected doesn't 
strike me as a failure of the language, given the language 
supports operator overloading. It's a failure in documentation to 
explain what the operators are intended to do, or a failure in 
implementation to behave as they should.

Lastly, if operators are intended to behave so strictly, why does 
this not extend then to binary arithmetic operators (+, -, *, /, 
%, etc.)
They don't follow the same rules as the binary relational 
operators, after all.