• Zach the Mystic <reachzachatgooglesmailservice dot.com> Feb 08 2012
• Timon Gehr <timon.gehr gmx.ch> Feb 08 2012
• Zach the Mystic <reachzachatgooglesmailservice dot.com> Feb 08 2012
• Timon Gehr <timon.gehr gmx.ch> Feb 08 2012

Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:

My goal is to be able to overload the "++" operator transparently to the 
code, but I can't.

import std.stdio;

struct Arc {
    int I = 0;
    // This is void, but the error appears under all return types
    void opUnary(string op)() if( op == "++" ) {
       ++I;
    }
}

struct HasArc {
     Arc myArc;
}

void main() {
    HasArc has;
    writefln(" Arc.I = %s", has.myArc.I); // Arc.I = 0

    has.myArc++; // Error: var has no effect in expression (__pitmp1481)

    // Okay, try this instead:
    auto UselessVar = has.myArc++; // Works fine

    writefln(" Arc.I = %s", has.myArc.I); // Arc.I = 1
}

Obviously the expression has an effect. Bug? If not, what is the right 
way to have the "++" operator pass that error test?

Thanks, Zach

Timon Gehr <timon.gehr gmx.ch> writes:

On 02/08/2012 10:48 PM, Zach the Mystic wrote:
 My goal is to be able to overload the "++" operator transparently to the
 code, but I can't.

 import std.stdio;

 struct Arc {
 int I = 0;
 // This is void, but the error appears under all return types
 void opUnary(string op)() if( op == "++" ) {
 ++I;
 }
 }

 struct HasArc {
 Arc myArc;
 }

 void main() {
 HasArc has;
 writefln(" Arc.I = %s", has.myArc.I); // Arc.I = 0

 has.myArc++; // Error: var has no effect in expression (__pitmp1481)

 // Okay, try this instead:
 auto UselessVar = has.myArc++; // Works fine

 writefln(" Arc.I = %s", has.myArc.I); // Arc.I = 1
 }

 Obviously the expression has an effect. Bug? If not, what is the right
 way to have the "++" operator pass that error test?

 Thanks, Zach


This is indeed a bug.

The expression is rewritten internally into (pseudo code)

(auto __pitmp1481 = has.myArc, has.myArc.opUnary!"++"(), __pitmp1481);

This introduces a sub-expression with no effect. You may want to file a 
bug report. For now, just using ++has.myArc; should work around the issue.

Zach the Mystic <reachzachatgooglesmailservice dot.com> writes:

On 2/8/12 4:58 PM, Timon Gehr wrote:
 This is indeed a bug.

 The expression is rewritten internally into (pseudo code)

 (auto __pitmp1481 = has.myArc, has.myArc.opUnary!"++"(), __pitmp1481);

 This introduces a sub-expression with no effect.


Is that because has.myArc.opUnary!"++"() is going to be ignored at that 
level of compiler activity? The compiler demands only that __pitmp1481 
has a value at that point?

 You may want to file a
 bug report. For now, just using ++has.myArc; should work around the issue.


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

Thanks, man. You're awesome!

Timon Gehr <timon.gehr gmx.ch> writes:

On 02/09/2012 12:47 AM, Zach the Mystic wrote:
 On 2/8/12 4:58 PM, Timon Gehr wrote:
 This is indeed a bug.

 The expression is rewritten internally into (pseudo code)

 (auto __pitmp1481 = has.myArc, has.myArc.opUnary!"++"(), __pitmp1481);

 This introduces a sub-expression with no effect.


 Is that because has.myArc.opUnary!"++"() is going to be ignored at that
 level of compiler activity? The compiler demands only that __pitmp1481
 has a value at that point?


This is the issue:

void main(){
     int x;
     ++x, x; // error
}

While the whole expression has an effect, the single 'x' does not have 
an effect.

 You may want to file a
 bug report. For now, just using ++has.myArc; should work around the
 issue.


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

 Thanks, man. You're awesome!


You're welcome. =)