Overloading relational operators separately; thoughts?

[Jonathan M Davis via Digitalmars-d]

On Thursday, September 29, 2016 20:16:00 pineapple via Digitalmars-d wrote:
> On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis
>
> wrote:
> > 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.
>
> I repeat: Your thinking like this limits D's viability for
> real-world code.
>
> Yes, I understand, the reason operator overloading works the way
> it does now is because members of the community wanted to
> arbitrarily limit programmers working in the language. Because
> they believed theirs was the singular appropriate way to use the
> language, to the exclusion of all others.
>
> I'm opinionated too, but I also have the presence of mind to
> recognize that my opinions are not universal, and they are
> certainly no basis for imposing arbitrary limits upon another
> person's behavior.

Except that the limits aren't arbitrary. Walter designed D's overloaded
operators for a specific purpose - to mimic the built-in operators. If you
want to make them do something else, and you're able to do so with how
they're designed, then that's your choice, but that's not what they're
designed for, and there is no attempt to support it.

You could just as easily ask why D's overloaded operators don't support
arbitrary operators, allowing you do stuff like opBinary!"#" to support # in
your code and complain that the current limitation on that is arbitary. The
feature _could_ have been made to do something like that, but that wasn't
its intended purpose, and there are reasons why it's a bad idea, so that's
not how D's operator overloading was designed.

The comparison operators have a specific purpose, and the functions for
overloading them were designed with that in mind. It just so happens that
that conflicts with what you want to do, but that doesn't mean that the
limitation is arbitrary. Rather, code correctness and conciseness of code
was valued, so they were overloaded using functions that could be used to
derive those operators rather than explicitly overloading each operator
individually. And because the ability to overload operators to do aribtrary
stuff was never one of the goals of the design, the fact that having
functions like opEquals and opCmp conflicted with the ability to overload
each comparison operator to do arbitrary stuff was not considered to be a
problem.

It's a design tradeoff that just doesn't happen to be in line with what you
want to do.

Just because C++ overloaded operators in a way that happens to support doing
arbitrary stuff with all of them doesn't mean that D needs to or that the
restriction is arbitrary.

> On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis
>
> wrote:
> > 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.
>
> Let me see if I understand your thinking:
>
> What you're saying is that because some people may not want to
> use a feature in a specific way, D should disallow anyone from
> using the feature in that way? That, somehow, contrary to logic,
> you believe this contributes positively to D's usability and
> appeal?

There are plenty of folks who think that overloading operators to mean
anything other than what they mean for the built-in types is bad practice.
Walter seems to be in agreement with that. So, when he designed D's operator
overloading, he did not attempt to support that. He didn't do a lot to
prevent it either, but in cases where it made sense to derive multiple
operators from a single function, he did so, even if it meant that you then
couldn't overload those operators to mean something other than what they
meant for the built-in types, because he considered what you got out of
combining them was worth far more than trying to support what many think is
bad practice.

t's not like Walter sat down and tried to prevent every misuse of operator
overloading. He simply didn't choose a design that fully supports such
misuse. Rather, he chose a design that better supports the intended use.
The tradeoff just so happens to leave you without being able to do something
that he considers to be bad practice, so he doesn't see it as a loss. And
neither do I. But that wasn't even the primary goal of why the operators
work they do. It's just a side effect of there being design goals that were
better served by a design that happened to inhibit operator overloading
abuse.

You'd have a much better argument if the language specifically did stuff to
hobble the abuse of overloaded operators. It doesn't. It just doesn't
implement operator overloading in a way that fully supports it. And Walter
is clearly not in favor of implementing such a language "enhancement,"
because he thinks that it would just enable bad code, so I think that it's
clear that it's not going to happen.

- Jonathan M Davis