Old-style operator overloads (such as opCom, opAnd, etc) have largely been superseded by new-style templated operator overloads (opUnary, opBinary, etc).

But the old-style operators are not listed on the deprecation page, they don't seem to be planned to be deprecated/removed. I recall a few times people mentioning they might get deprecated at some point.

There's also a bugzilla issue from a year ago asking for warnings when old-style operator overloads are used:
https://issues.dlang.org/show_bug.cgi?id=10320

E.g. I've wanted to replace old-style operators from Phobos with the new-style ones (https://github.com/D-Programming-Language/phobos/pull/2093), but this brought up some issues w.r.t. the compilation performance when using templates and potential object bloat as well.

The reason I was replacing them is because I was under the impression the old-style operators are going away, and it's best to keep such code out of Phobos or users might end up writing that kind of code too.

I think it's time we get an official stance on this before it's too late.

On Tue, 22 Apr 2014 10:21:40 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> Old-style operator overloads (such as opCom, opAnd, etc) have largely been superseded by new-style templated operator overloads (opUnary, opBinary, etc).
>
> But the old-style operators are not listed on the deprecation page, they don't seem to be planned to be deprecated/removed. I recall a few times people mentioning they might get deprecated at some point.
>
> There's also a bugzilla issue from a year ago asking for warnings when old-style operator overloads are used:
> https://issues.dlang.org/show_bug.cgi?id=10320
>
> E.g. I've wanted to replace old-style operators from Phobos with the new-style ones (https://github.com/D-Programming-Language/phobos/pull/2093), but this brought up some issues w.r.t. the compilation performance when using templates and potential object bloat as well.
>
> The reason I was replacing them is because I was under the impression the old-style operators are going away, and it's best to keep such code out of Phobos or users might end up writing that kind of code too.
>
> I think it's time we get an official stance on this before it's too late.

I filed an enhancement a while ago, that makes it completely feasible to have 0-impact forwarding from the new style operators to the existing operators. Supposedly it is included since Feb 2013, I haven't ever tested it.

See here: https://issues.dlang.org/show_bug.cgi?id=5893

Oh wait look, you were involved :)

I think a "useOldOperators" mixin template would be awesome to have for transitioning.

-Steve

On Tuesday, 22 April 2014 at 14:21:42 UTC, Andrej Mitrovic wrote:
> this brought up some issues w.r.t. the compilation performance when using templates and potential object bloat as well.

If templates are an issue, you can always just write a non-template function, and template the alias:

```D
alias opUnary(string : "++") = operatorIncrement;

auto operatorIncrement()
{
    ...
}
```

"Andrej Mitrovic"  wrote in message news:ifghzjafvfqrqkhlpinc@forum.dlang.org...

> Old-style operator overloads (such as opCom, opAnd, etc) have largely been superseded by new-style templated operator overloads (opUnary, opBinary, etc).

I prefer the old ones mainly because the names are better and the code easier to read.  When you are implementing one operator per function (ie most of the time) the extra template syntax is just unnecessary noise.

T opMul(T other)

vs

T opBinary(string op : "*")(T other)

The old names were chosen to match what the operations were supposed to be, not for the syntax.  In that regard the new syntax is a step backwards. 

Daniel Murphy:

> I prefer the old ones mainly because

You can't remove the new ones, and you can't keep two different operator overloading systems in a language.

Bye,
bearophile

"bearophile"  wrote in message news:pvkqreqswxwusojgpplp@forum.dlang.org... 

> you can't keep two different operator overloading systems in a language.

Of course we can.

On Tue, 22 Apr 2014 13:43:58 -0400, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "bearophile"  wrote in message news:pvkqreqswxwusojgpplp@forum.dlang.org...
>> you can't keep two different operator overloading systems in a language.
>
> Of course we can.

If the old behavior can be exactly mimiced, I think we can get rid of the old behavior.

Less code in the compiler, less complexity in the language.

-Steve

On Tuesday, 22 April 2014 at 17:43:58 UTC, Daniel Murphy wrote:
> Of course we can.

We have "alias a = b;" and "alias b a;", so there's precedent for having two ways of doing exactly the same thing.

"Steven Schveighoffer"  wrote in message news:op.xeqcf3vbeav7ka@stevens-macbook-pro-2.local...

> If the old behavior can be exactly mimiced, I think we can get rid of the old behavior.

Can != Should

> Less code in the compiler, less complexity in the language.

More complexity in user code. 

On Tue, 22 Apr 2014 14:15:21 -0400, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message news:op.xeqcf3vbeav7ka@stevens-macbook-pro-2.local...
>
>> If the old behavior can be exactly mimiced, I think we can get rid of the old behavior.
>
> Can != Should

Sorry I misspoke. We *should* :)

>> Less code in the compiler, less complexity in the language.
>
> More complexity in user code.

A mixin statement is not complexity.

-Steve