Overloading relational operators separately; thoughts?

[Jonathan M Davis via Digitalmars-d]

On Thursday, September 29, 2016 19:11:55 pineapple via Digitalmars-d wrote:
> On Thursday, 29 September 2016 at 18:38:42 UTC, Jonathan M Davis
>
> wrote:
> > You just can't use overloaded operators for it, since it would
> > not be in line with what the operators are supposed to mean and
> > be used for.
>
> This is not a valid argument because what an operator is
> "supposed to mean" is up to the programmer who wishes to
> implement that operator for their data type. Not up to me. Not up
> to you.
>
> Your thinking like this limits D's viability for real-world code.
> Programmers do not care how you think they are supposed to use
> the language. They care only that they can get their job done in
> a way that makes sense to them. What makes sense to them will not
> be the same as what makes sense to you. Relinquish the notion
> that you or anyone can have the slightest idea what any language
> feature is "supposed to mean and be used for".

Every language feature is designed with a purpose. Sometimes that purpose is
broader than other times. And once the feature is there, you can do whatever
is legal to do with the feature whether that was really what it was intended
for or not, but if what you're trying to do goes against what the feature
was designed for, don't expect to get support for making it do more stuff
that goes against why it's in the language in the first place - especially
when plenty of folks think that what you're trying to do is bad practice.

The reality of the matter is that D's operator overloading was designed
specifically so that you could overload the built-in operators to be used
with your own types so that they could act like the built-in types. It was
not intended or designed to allow for the symbols use for those operators to
then be used for other arbitrary stuff that's unrelated to what they mean
for the built-in types. The decisions made in how the operators are
overloaded were geared entirely towards better supporting having your types
act like built-in types, and none of it was designed with the idea that you
would do arbitrary stuff via overloading the operators (which is why the
language does stuff like derive some operators from others; it supports the
goal of making them work like the built-in types, and supporting arbitrary
usage of those operators was never a goal, so losing out on the ability is
not considered to be a problem). The language can't stop you from doing at
least some arbitrary stuff with them (like making + do subtraction), but the
whole goal was for user-defined types to be able to act like the built-in
types, and as such, it would make no sense to alter them towards being
treated like symbols that you can do whatever you want with.

And there are plenty of folks who think that overloading operators to do
stuff fundamentally different from how they work for the built-in types is
bad practice and consider it to be an abuse of operator overloading. So, the
fact that D limits that is going to be viewed as positive by many folks.

You're obviously free to do whatever you want with overloaded operators in D
within the bounds of how they work, but we're not going to change them with
the goal of making them less restrictive about mimicking the operators for
the built-in types when the entire reason that they're in the language is to
mimic the operators for the built-in types. And if you do try and make them
work differently than for the built-in types, then your code is likely to be
considered by many to be following bad programming practices.

- Jonathan M Davis