templating opEquals/opCmp (e.g. for DSL/expression templates)

Jonathan M Davis newsgroup.d at jmdavisprog.com
Wed Feb 13 00:24:48 UTC 2019


On Tuesday, February 12, 2019 5:09:19 PM MST Nicholas Wilson via 
Digitalmars-d wrote:
> On Tuesday, 12 February 2019 at 23:24:54 UTC, Olivier FAURE wrote:
> > On Tuesday, 12 February 2019 at 13:22:12 UTC, Nicholas Wilson
> >
> > wrote:
> >> Oh well, more things to discuss at dconf. That whole thread
> >> seems to be Walter either being stubborn or not getting it (or
> >> both).
> >
> > Or your proposal has drawbacks you're underestimating.
>
> ... go on. I don't see any drawbacks: its backwards compatible,
> intuitive (behaves like opBinary), useful. We should be making
> design decisions based on merit, not dismissing them not
> potential for abuse.

Except that what you're proposing is precisely so that you can more easily
abuse certain operators when overloading them. IMHO, if an operator is being
overloaded in a manner that doesn't fit what you get with the basic
arithmetic types, then that's bad practice. I know that some folks like to
do it (especially in C++), but that's one of the big reasons that some
languages (like Java) chose to not have operator overloading at all. People
kept using them to mean things that didn't match their meaning for the
built-in types. Such operator overloading abuse results in code that's
harder to understand and maintain, because the operators are not being used
with their normal meaning. It also doesn't play well with generic code,
because such code is going to assume the normal arithmetic meanings for
those operators, and so having a type that uses them differently with such
code will tend to result in incorrect behavior (or in some cases, the code
won't even compile).

We can't completely eliminate operator overloading abuse (e.g. someone doing
something dumb like making + mean -), but just because it's possible to
abuse one operator doesn't mean that we should make easier to abuse another.

- Jonathan M Davis





More information about the Digitalmars-d mailing list