digitalmars.D.bugs - [Issue 3167] New: Passing result of a function call as ref argument no longer works
- d-bugmail puremagic.com (33/34) Jul 12 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (11/11) Jul 12 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (14/14) Jul 12 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (12/12) Jul 12 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (12/14) Aug 06 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (19/21) Aug 06 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (10/10) Aug 06 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (10/10) Aug 14 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (19/20) Aug 15 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (10/10) Oct 15 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (16/16) Jan 29 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (11/18) Jan 29 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (22/29) Jan 29 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (8/8) Jan 29 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (46/49) Jan 29 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (27/30) Feb 07 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3167
- d-bugmail puremagic.com (8/14) Feb 07 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3167
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.
struct X {
}
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
d-bugmail puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=3167
BCS <shro8822 vandals.uidaho.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |shro8822 vandals.uidaho.edu
---
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
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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=3167
Don <clugdbug yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clugdbug yahoo.com.au
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.
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
http://d.puremagic.com/issues/show_bug.cgi?id=3167
Bill Baxter <wbaxter gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wbaxter gmail.com
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
http://d.puremagic.com/issues/show_bug.cgi?id=3167 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
http://d.puremagic.com/issues/show_bug.cgi?id=3167
Walter Bright <bugzilla digitalmars.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla digitalmars.com
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
http://d.puremagic.com/issues/show_bug.cgi?id=3167What 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
http://d.puremagic.com/issues/show_bug.cgi?id=3167
Don <clugdbug yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |2korden gmail.com
*** 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
http://d.puremagic.com/issues/show_bug.cgi?id=3167
Walter Bright <bugzilla digitalmars.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
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
http://d.puremagic.com/issues/show_bug.cgi?id=3167
Andrei Alexandrescu <andrei metalanguage.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andrei metalanguage.com
12:27:07 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.
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
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
15:00:25 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.
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
http://d.puremagic.com/issues/show_bug.cgi?id=3167 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
http://d.puremagic.com/issues/show_bug.cgi?id=3167
Steven Schveighoffer <schveiguy yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |schveiguy yahoo.com
19:24:11 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.
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
http://d.puremagic.com/issues/show_bug.cgi?id=3167 03:05:52 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.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
http://d.puremagic.com/issues/show_bug.cgi?id=3167It 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: -------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.
Feb 07 2010