www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - opAddAssign still works

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
I just made a startling discovery: the old operator overload routines  
still work in 2.045

Is this intended?


struct S
{
     int x;
     S opAddAssign(ref const S other)
     {
         x += other.x;
         return this;
     }
}

void foo(S s)
{
     s += s;
}

generates no error.

And in fact, neither does this:


struct S
{
     int x;
     S opAddAssign(ref const S other)
     {
         x += other.x;
         return this;
     }

     S opOpAssign(string op)(ref const S other) if (op == "+=")
     {
         static assert(0, "fail!");
     }
}

void foo(S s)
{
     s += s;
}

But if I only have the template version, it does use the template.

-Steve
May 10 2010
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Steven Schveighoffer wrote:

 I just made a startling discovery: the old operator overload routines 
 still work in 2.045
 
 Is this intended?


I don't know, but I am happy that they still work. I haven't gotten 
around to changing my code to use the new syntax yet. :)

I hope the old syntax remains as a deprecated feature and stays 
supported for the next 15 years or so... :)

Ali
May 10 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 10 May 2010 17:58:37 -0400, Ali Çehreli <acehreli yahoo.com> wrote:


 Steven Schveighoffer wrote:

 I just made a startling discovery: the old operator overload routines  
 still work in 2.045
  Is this intended?


 I don't know, but I am happy that they still work. I haven't gotten  
 around to changing my code to use the new syntax yet. :)

 I hope the old syntax remains as a deprecated feature and stays  
 supported for the next 15 years or so... :)



Well, I've been doing it for dcollections, and I came across this blocker:

http://d.puremagic.com/issues/show_bug.cgi?id=4174

-Steve
May 10 2010
prev sibling parent reply Trass3r <un known.com> writes:
Yeah it still works for compatibility reasons but is deprecated.
May 10 2010
next sibling parent reply Pelle <pelle.mansson gmail.com> writes:
On 05/11/2010 01:38 AM, Trass3r wrote:

 Yeah it still works for compatibility reasons but is deprecated.


Not yet, it's not. To compile something that's deprecated, you will need 
the -d switch.

Right now, both are allowed, but the old one is scheduled for 
deprecation and presumably later removal. :)
May 11 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Pelle:

 Not yet, it's not. To compile something that's deprecated, you will need 
 the -d switch.


That's for user code marked with 'deprecated':
http://www.digitalmars.com/d/2.0/attribute.html#deprecated
I don't think it is designed to work with compiler/language features too.

The D1 compiler has a switch (-v1), that's missing in D2, for deprecated
compiler features, maybe something similar will be put back.

Bye,
bearophile
May 11 2010
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
bearophile wrote:


 Pelle:

 Not yet, it's not. To compile something that's deprecated, you will need 
 the -d switch.


 That's for user code marked with 'deprecated':
 http://www.digitalmars.com/d/2.0/attribute.html#deprecated
 I don't think it is designed to work with compiler/language features too.

 The D1 compiler has a switch (-v1), that's missing in D2, for deprecated
compiler features, maybe something similar will be put back.

 Bye,
 bearophile


Actually the switch has nothing to do with deprecation. Originally D2
was developed and released as the same binary as D1. If you wanted to
compile for version 1 you passed the -v1 switch, otherwise you were
compiling version 2.

Don't ask me why the switch is still there.
May 11 2010
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 10 May 2010 19:38:53 -0400, Trass3r <un known.com> wrote:


 Yeah it still works for compatibility reasons but is deprecated.


Yeah, but should the old method override the new one?

I assumed one nice thing about "backwards compatibility" is you could do  
something like this:

T opOpAssign(string op)(T other) if (op == "+=")
{
    return opAddAssign(other);
}

But this function never gets called.  I found out recently that template  
functions are not allowed in interfaces, which makes it impossible to use  
the new operator overloads on interfaces.

-Steve
May 11 2010
next sibling parent reply Trass3r <un known.com> writes:
 I found out recently that template
 functions are not allowed in interfaces, which makes it impossible to use
 the new operator overloads on interfaces.


Wow that should find its way into bugzilla.
May 11 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 May 2010 08:52:47 -0400, Trass3r <un known.com> wrote:


 I found out recently that template
 functions are not allowed in interfaces, which makes it impossible to  
 use
 the new operator overloads on interfaces.


 Wow that should find its way into bugzilla.


Already there :)

http://d.puremagic.com/issues/show_bug.cgi?id=4174

It was the minimal case I was working on creating where I discovered the  
old operator functions still work.

-Steve
May 11 2010
prev sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Steven Schveighoffer <schveiguy yahoo.com> wrote:


 But this function never gets called.  I found out recently that template  
 functions are not allowed in interfaces, which makes it impossible to  
 use the new operator overloads on interfaces.


The problem is however, that template functions can't be virtual, and
thus can't be stuffed into interfaces. Mayhaps however, specific
instantiations could be.

Of course, implementing some kind of dynamic vtable, that could be
updated at link-time, would make many kinds of magic possible, and
might be a solution. No idea how possible this is, though.

-- 
Simen
May 11 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 May 2010 09:14:37 -0400, Simen kjaeraas  
<simen.kjaras gmail.com> wrote:


 Steven Schveighoffer <schveiguy yahoo.com> wrote:


 But this function never gets called.  I found out recently that  
 template functions are not allowed in interfaces, which makes it  
 impossible to use the new operator overloads on interfaces.


 The problem is however, that template functions can't be virtual, and
 thus can't be stuffed into interfaces. Mayhaps however, specific
 instantiations could be.

 Of course, implementing some kind of dynamic vtable, that could be
 updated at link-time, would make many kinds of magic possible, and
 might be a solution. No idea how possible this is, though.


It is planned for interfaces to be able to contain template member  
functions, those functions would not be virtual or overridable, and would  
need to be expressed completely in terms of the interface.

They are like final interface functions.

I assumed this was already done, as it was a mitigating factor when  
fleshing out the new operator design that you could simulate previous  
behavior by creating a virtual function that then was called by your  
template operator function.

-Steve
May 11 2010