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