• kris <foo bar.com> Feb 18 2007
• Walter Bright <newshound digitalmars.com> Feb 18 2007
• Gregor Richards <Richards codu.org> Feb 19 2007
• kris <foo bar.com> Feb 19 2007
• kris <foo bar.com> Feb 19 2007
• Walter Bright <newshound digitalmars.com> Feb 19 2007

kris <foo bar.com> writes:

Using static opAssign() apparently has some codegen issues. The 
following snippets are two variations of the same code; the first one is 
correct while the second is broken. Only flag enabled is -g. First, the 
operational version, which invokes this.opAssign() explicitly:

; FileProxy parent = this.opAssign(this.parent());
mov	EAX,-010h[EBP]
call	near ptr _D5tango2io8FilePath8FilePath6parentMFZAa
push	EDX
push	EAX
call	near ptr 
_D5tango2io9FileProxy9FileProxy8opAssignFAaZC5tango2io9FileProxy9FileProxy
mov	-0Ch[EBP],EAX

; char[] name = parent.name;
call	near ptr _D5tango2io8FilePath8FilePath4nameMFZAa
mov	-8[EBP],EAX
mov	-4[EBP],EDX


And now the busted version using opAssign() implicitly:


; FileProxy parent = this.parent();
mov	EAX,-010h[EBP]
call	near ptr _D5tango2io8FilePath8FilePath6parentMFZAa
push	EDX
push	EAX
call	near ptr 
_D5tango2io9FileProxy9FileProxy8opAssignFAaZC5tango2io9FileProxy9FileProxy
 doh! where did the return value go? <<<






; char[] name = parent.name;
mov	EAX,-0Ch[EBP]
call	near ptr _D5tango2io8FilePath8FilePath4nameMFZAa
mov	-8[EBP],EAX
mov	-4[EBP],EDX


It's pretty clear that the broken version is discarding the result of 
the implicit opAssign() call; the assignment is simply being dropped.

I'm copying this here since it'll just get lost amongst the weeds in 
d.bugs. I don't have a small test case: took hours to track this down as 
it was, and it's deep in the Tango library.

Walter Bright <newshound digitalmars.com> writes:

	a = b;

is replaced with:

	a.opAssign(b);

not:

	a = a.opAssign(b);

The return value of opAssign comes in to play with:

	c = a = b;

which is rewritten as:

	c = a.opAssign(b);

Gregor Richards <Richards codu.org> writes:

Walter Bright wrote:
     a = b;
 
 is replaced with:
 
     a.opAssign(b);
 
 not:
 
     a = a.opAssign(b);
 
 The return value of opAssign comes in to play with:
 
     c = a = b;
 
 which is rewritten as:
 
     c = a.opAssign(b);


This makes quite a bit of sense, actually. It's consistent.

But it begs the question: Is there a way to do what is desired here? 
That is:

SomeClass a = "Instance generated by a string";

  - Gregor Richards

kris <foo bar.com> writes:

Walter Bright wrote:
     a = b;
 
 is replaced with:
 
     a.opAssign(b);
 
 not:
 
     a = a.opAssign(b);
 
 The return value of opAssign comes in to play with:
 
     c = a = b;
 
 which is rewritten as:
 
     c = a.opAssign(b);



Doh! Doh! Doh!

My bad; I saw this elsewhere and just assumed it would operate correctly.

The syntax, however, is very clean. Importantly, it supports the 
unification or /centralization/ of all those 'new' invocations. I'd go 
so far as to say such a syntax could represent a bridge between OO and 
scripting:

----
String s = "mystring";
----

----
File f = "/foo/bar.d";
----

----
Regex r = "^(.*)$";
----

There's a fairly wide range of simple applicability for this kinda' 
thing. Would be great if static opAssign() could support this, or some 
other operator were enabled?

How about it?

kris <foo bar.com> writes:

kris wrote:
 Walter Bright wrote:
 
     a = b;

 is replaced with:

     a.opAssign(b);

 not:

     a = a.opAssign(b);

 The return value of opAssign comes in to play with:

     c = a = b;

 which is rewritten as:

     c = a.opAssign(b);


 
 
 Doh! Doh! Doh!
 
 My bad; I saw this elsewhere and just assumed it would operate correctly.
 
 The syntax, however, is very clean. Importantly, it supports the 
 unification or /centralization/ of all those 'new' invocations. I'd go 
 so far as to say such a syntax could represent a bridge between OO and 
 scripting:
 
 ----
 String s = "mystring";
 ----
 
 ----
 File f = "/foo/bar.d";
 ----
 
 ----
 Regex r = "^(.*)$";
 ----
 
 There's a fairly wide range of simple applicability for this kinda' 
 thing. Would be great if static opAssign() could support this, or some 
 other operator were enabled?
 
 How about it?



One note: an operator is suggested so that structs could take advantage 
of this also. Otherwise, some kind of 'property' assignment for a ctor 
might have done the trick?

Walter Bright <newshound digitalmars.com> writes:

kris wrote:
 The syntax, however, is very clean. Importantly, it supports the 
 unification or /centralization/ of all those 'new' invocations. I'd go 
 so far as to say such a syntax could represent a bridge between OO and 
 scripting:
 
 ----
 String s = "mystring";
 ----
 
 ----
 File f = "/foo/bar.d";
 ----
 
 ----
 Regex r = "^(.*)$";
 ----
 
 There's a fairly wide range of simple applicability for this kinda' 
 thing. Would be great if static opAssign() could support this, or some 
 other operator were enabled?
 
 How about it?


I don't get it. Exactly what transformation are you looking for?