www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3167] New: Passing result of a function call as ref argument no longer works

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167

           Summary: Passing result of a function call as ref argument no
                    longer works
           Product: D
           Version: 1.046
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: nfxjfg gmail.com


The following code works with dmd 1.045, but not with 1.046. It seems you can
no longer pass the result of a function call as argument to ref parameters.

While it's debatable if the old or new behavior is better, the chan ge breaks
existing code.



} X i() { return X.init; } void foo(ref X x) { } void foo() { foo(i()); //line 12 } << This fails with test.d(12): Error: cannot assign to function call -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 12 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


BCS <shro8822 vandals.uidaho.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |shro8822 vandals.uidaho.edu




--- Comment #1 from BCS <shro8822 vandals.uidaho.edu>  2009-07-12 09:00:22 PDT
---
I think this is invalid because the error message is totally correct. I expect
that this was a bug in older versions.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 12 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


Jarrett Billingsley <jarrett.billingsley gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jarrett.billingsley gmail.c
                   |                            |om




--- Comment #2 from Jarrett Billingsley <jarrett.billingsley gmail.com> 
2009-07-12 09:44:06 PDT ---
Oh, man.  This breaks so much of MiniD because I use "push(t, MDValue(...))"
all over the place, where MDValue is a struct with a static opCall and push
takes a ref MDValue.  

I wonder what bug was fixed that caused this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 12 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


Christian Kamm <kamm-removethis incasoftware.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kamm-removethis incasoftwar
                   |                            |e.de




--- Comment #3 from Christian Kamm <kamm-removethis incasoftware.de> 
2009-07-12 12:35:26 PDT ---
I'm fairly sure this was by design (bug 2621) in D 2.026, but I don't think it
was expected to seep through to D1.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 12 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au




--- Comment #4 from Don <clugdbug yahoo.com.au>  2009-08-06 00:08:01 PDT ---
(In reply to comment #3)
 I'm fairly sure this was by design (bug 2621) in D 2.026, but I don't think it
 was expected to seep through to D1.

It might be related to the fix for bug #2323 ? My patch for that bug was rejected, so I don't know what changes were made. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 06 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


Bill Baxter <wbaxter gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wbaxter gmail.com




--- Comment #5 from Bill Baxter <wbaxter gmail.com>  2009-08-06 06:40:55 PDT ---
(In reply to comment #3)
 I'm fairly sure this was by design (bug 2621) in D 2.026, but I don't think it
 was expected to seep through to D1.

I hope you're right. In D2 you can have the ref argument be const (which I hope eliminates the error), but in D1 you have no such option. So you often have to resort to making arguments 'ref' for efficiency even when the function doesn't modify the argument. Also the error message could be a little clearer. Something like "Can't pass a temporary to a function taking a ref argument" would be a lot clearer I think. Passing something to a function taking a ref does not necessarily imply assigning to that ref argument in D1, for the reason stated above. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 06 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167





--- Comment #6 from Don <clugdbug yahoo.com.au>  2009-08-06 12:24:14 PDT ---
This change is clearly caused by the addition of the new function

Expression *CallExp::modifiableLvalue(Scope *sc, Expression *e)

in expression.c. Comment it out to restore the old behaviour. It doesn't seem
to be necessary for any bug fixes -- eg, removing it doesn't reactivate bug
2323.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 06 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com




--- Comment #7 from Walter Bright <bugzilla digitalmars.com>  2009-08-14
22:39:29 PDT ---
What if X is replaced by int? Should that work? I think it's a problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 14 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167





--- Comment #8 from Bill Baxter <wbaxter gmail.com>  2009-08-15 03:38:43 PDT ---
(In reply to comment #7)
 What if X is replaced by int? Should that work? I think it's a problem.

Well, probably not, because 'int' is not a large struct. So the only reason to pass it 'ref' would be if you wanted to modify it. But then you get into a case like X add(X)(ref X a, ref X b) { return a + b; } where foo takes ref in order to accept large value types without inordinate amounts of copying. But someone might want to pass int too. It would be odd if that code worked for certain size arguments but not others. If you're going to change the D1 behavior anyway, the best solution in my opinion would be to give D1 a way to specify that you want to pass by reference for efficiency, but don't want to modify the value. Give it a weak form of const parameters like C has. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 15 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |2korden gmail.com


--- Comment #9 from Don <clugdbug yahoo.com.au> 2009-10-15 05:27:05 PDT ---
*** Issue 2852 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #10 from Walter Bright <bugzilla digitalmars.com> 2010-01-29
11:55:29 PST ---
I'm going to mark this as invalid, as function return values should be rvalues,
and rvalues cannot be references, even if the vagaries of the implementation
make that possible.

The reason is "vagaries of the implementation", so it may work on one
implementation but not another. Currently, whether it (used to) work or not
also depended on the contents of the struct being returned.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei metalanguage.com


--- Comment #11 from Andrei Alexandrescu <andrei metalanguage.com> 2010-01-29
12:27:07 PST ---
(In reply to comment #10)
 I'm going to mark this as invalid, as function return values should be rvalues,
 and rvalues cannot be references, even if the vagaries of the implementation
 make that possible.
 
 The reason is "vagaries of the implementation", so it may work on one
 implementation but not another. Currently, whether it (used to) work or not
 also depended on the contents of the struct being returned.

Why should we leave this to vagaries? An rvalue is not an lvalue, period. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


Eldar Insafutdinov <e.insafutdinov gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |e.insafutdinov gmail.com


--- Comment #12 from Eldar Insafutdinov <e.insafutdinov gmail.com> 2010-01-29
15:00:25 PST ---
(In reply to comment #10)
 I'm going to mark this as invalid, as function return values should be rvalues,
 and rvalues cannot be references, even if the vagaries of the implementation
 make that possible.
 
 The reason is "vagaries of the implementation", so it may work on one
 implementation but not another. Currently, whether it (used to) work or not
 also depended on the contents of the struct being returned.

This test case fails for me with the latest dmd: struct X { } X i() { return X.init; } void foo(const ref X x) { } void foo() { foo(i()); //line 12 } This bug is not invalid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167



--- Comment #13 from Walter Bright <bugzilla digitalmars.com> 2010-01-29
15:50:10 PST ---
It is invalid code because you are taking a reference to the return value of a
function. Functions return, by definition, rvalues. You cannot take a reference
to an rvalue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy yahoo.com


--- Comment #14 from Steven Schveighoffer <schveiguy yahoo.com> 2010-01-29
19:24:11 PST ---
(In reply to comment #13)
 It is invalid code because you are taking a reference to the return value of a
 function. Functions return, by definition, rvalues. You cannot take a reference
 to an rvalue.

This breaks custom types. Who are you as the compiler to assume my type is an rvalue? e.g. class MyClass { struct myForwardRange {...} property myForwardRange all() {...} } void copy(R1, R2)(ref R1 inputrange, ref R2 outputrange) { ... } void foo(MyClass mc, OutputRange r) { copy(mc.all, r); } Another case: struct LargeStruct { int[100] bigarray; void print(streamtype s) {s.print(bigarray);} } class X { LargeStruct createalargestruct() {...} } void foo(X x) { x.createalargestruct().print(stdout); } Also, if you can't call properties on a struct, which essentially needs a reference to the struct, then you can't get any properties from a returned struct. This rule is way too limiting. at the very least, const rvalue references need to be allowed for any reasonable value types that are not just POD to be created. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167



--- Comment #15 from Eldar Insafutdinov <e.insafutdinov gmail.com> 2010-02-07
03:05:52 PST ---
(In reply to comment #13)
 It is invalid code because you are taking a reference to the return value of a
 function. Functions return, by definition, rvalues. You cannot take a reference
 to an rvalue.

But it used to work before. Just simple case, that I encountered today (I'm sure many of us had similar experience(: struct vec3d { double x,y,z; static vec3d opCall(double x, double y, double z) { ... } } vec3d vecMul(ref const vec3d a, ref const vec3d b) { ... } void main() { vec3d a; ... vec3d b = opMul(a, vec3d(0., 0., 1.); // doesn't work because opCall returns rvalue } I don't see anything wrong with this code, as const protects arguments from being modified. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 07 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3167



--- Comment #16 from Don <clugdbug yahoo.com.au> 2010-02-07 07:21:15 PST ---
(In reply to comment #15)
 (In reply to comment #13)
 It is invalid code because you are taking a reference to the return value of a
 function. Functions return, by definition, rvalues. You cannot take a reference
 to an rvalue.

But it used to work before.

It didn't. It only seemed to work. In simple cases it happened to work, in more difficult cases it failed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 07 2010