www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's the status of old-style operator overloads in D2?

reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
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.
Apr 22 2014
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 22 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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()
{
     ...
}
```
Apr 22 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Apr 22 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Apr 22 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Apr 22 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 22 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Apr 22 2014
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 22 2014
prev sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
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.
Apr 22 2014
next sibling parent Matt Soucy <msoucy csh.rit.edu> writes:
On 04/22/2014 02:06 PM, Brian Schott wrote:

 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.


Except that's another case of "we had one way to do it, we want to move to a
different way", isn't it?

-- 
Matt Soucy
http://msoucy.me/
Apr 22 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Brian Schott:


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


I've just filed a bug report:
https://issues.dlang.org/show_bug.cgi?id=12615

Bye,
bearophile
Apr 22 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 22/04/14 20:06, Brian Schott wrote:


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


I believe that for aliasing function pointers only the latter syntax works.

-- 
/Jacob Carlborg
Apr 22 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:


 I believe that for aliasing function pointers only the latter 
 syntax works.


It's a bug that needs to be fixed before the deprecation of old 
style alias syntax...

Bye,
bearophile
Apr 23 2014
prev sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 22 April 2014 at 15:50:21 UTC, Daniel Murphy wrote:

 "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.


Does this work if test is in a different module from main?

struct test
{
	private int opBinary(string op: "*")(test other) { return 3; }
	public alias opMul = opBinary!"*";
}

void main()
{
	test t1 = test();
	test t2 = test();
	auto n = t1 * t2;
	assert(n == 3);
}
Apr 22 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 22 April 2014 at 21:35:31 UTC, Meta wrote:

 Does this work if test is in a different module from main?

 struct test
 {
 	private int opBinary(string op: "*")(test other) { return 3; }
 	public alias opMul = opBinary!"*";
 }

 void main()
 {
 	test t1 = test();
 	test t2 = test();
 	auto n = t1 * t2;
 	assert(n == 3);
 }


And it appears it does.
Apr 22 2014
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 22 Apr 2014 18:54:41 -0400, Meta <jared771 gmail.com> wrote:


 On Tuesday, 22 April 2014 at 21:35:31 UTC, Meta wrote:

 Does this work if test is in a different module from main?

 struct test
 {
 	private int opBinary(string op: "*")(test other) { return 3; }
 	public alias opMul = opBinary!"*";
 }

 void main()
 {
 	test t1 = test();
 	test t2 = test();
 	auto n = t1 * t2;
 	assert(n == 3);
 }


 And it appears it does.


This changes the dynamics. opMul is not a template, which is important for  
classes.

This also works, and if encapsulated into a mixin, will be a drop-in fix  
for existing opMul and friends code:

struct test
{
    alias opBinary(string op: "*") = blah; // to demonstrate it's not  
actually calling opMul because of old-style operators

    int blah(test other) {return 3;}
}

BTW, I don't know when template alias got so cool, but I like it :)

-Steve
Apr 23 2014