[Issue 6221] Should be possible to pass struct function returns by 'const ref'.
https://issues.dlang.org/show_bug.cgi?id=6221 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |FIXED --- Comment #7 from Mathias LANG --- This is now possible to do, using `-preview=in` and `in` instead of `const ref`, with DMD > 2.094.0. --
[Issue 6221] Should be possible to pass struct function returns by 'const ref'.
http://d.puremagic.com/issues/show_bug.cgi?id=6221 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com 2012-02-09 14:24:46 PST --- I think that const auto ref does the trick, assuming that that works with opCmp, but for some reason, it only works with templated functions at the moment. I thought that it was supposed to work with non-templated functions as well. If it doesn't, then I guess that the forced solution is to define an overload which takes a const ref and one which takes the argument by value. It would be much simpler if const ref could take a temporary, but Andrei is dead set against that solution. A related issue is the fact that boo6221(S6221(5)); compiles while boo6221(blah6221()); does not, since (for reasons that I've never understood) a struct literal is considered an lvalue: issue# 5889. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6221] Should be possible to pass struct function returns by 'const ref'.
http://d.puremagic.com/issues/show_bug.cgi?id=6221 --- Comment #5 from Don clugd...@yahoo.com.au 2011-07-01 03:12:01 PDT --- (In reply to comment #4) Shouldn't opCmp be relaxed like opEquals in bug 3659? It is indeed the same issue. But I'm not convinced by the proposed solution in bug 3659. We don't need more options -- we just need one GOOD one. IMHO, this is *the* remaining black hole in the language. We have a zoo of parameter passing options -- in, inout, out, ref, const ref, auto ref -- and yet it's not possible to express the most basic parameter passing option: I want read-only access from this value, and I give the compiler freedom to pass it as efficiently as possible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6221] Should be possible to pass struct function returns by 'const ref'.
http://d.puremagic.com/issues/show_bug.cgi?id=6221
--- Comment #2 from Don clugd...@yahoo.com.au 2011-06-29 23:54:17 PDT ---
(In reply to comment #1)
I think this bug is invalid. A value-type return is an rvalue, and Andrei has
made it very clear in his posts and in TDPL that rvalues cannot be bound to
const ref parameters. I think his reasoning is that this ability was a
mistake
in C++, though I haven't gotten consistent answers as to why.
That's probably true. But that has consequences. We can't discard that C++
behaviour and yet keep the C++ behaviour of using const ref in operator
overloads:
The fact that it works with opCmp in one direction is I think a relaxation of
the rules, because struct returns would be near useless if you couldn't call
any methods on them.
This is a serious problem. opCmp behaviour MUST be symmetrical.
S foo() {...}
S x;
x foo()
foo() x
foo() foo()
If any of these compile, they must all compile.
As far as I can tell, a 'const ref' parameter on pretty much any operator
overload, is a bug. In fact it's difficult to come up with _any_ scenarios
where 'const ref' makes sense.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6221] Should be possible to pass struct function returns by 'const ref'.
http://d.puremagic.com/issues/show_bug.cgi?id=6221 --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com 2011-06-30 07:24:09 PDT --- Like I said, I don't know what the right solution is. Previously I thought auto ref was the solution, but I'm not so sure. I agree operators need to accept rvalues, but I don't think const ref will be acceptable to Andrei. If this bug report was changed to it should be possible to pass both rvalues and lvalues to operators, it would be a valid bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6221] Should be possible to pass struct function returns by 'const ref'.
http://d.puremagic.com/issues/show_bug.cgi?id=6221 --- Comment #4 from kenn...@gmail.com 2011-06-30 07:52:16 PDT --- Shouldn't opCmp be relaxed like opEquals in bug 3659? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6221] Should be possible to pass struct function returns by 'const ref'.
http://d.puremagic.com/issues/show_bug.cgi?id=6221 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer schvei...@yahoo.com 2011-06-29 07:55:14 PDT --- I think this bug is invalid. A value-type return is an rvalue, and Andrei has made it very clear in his posts and in TDPL that rvalues cannot be bound to const ref parameters. I think his reasoning is that this ability was a mistake in C++, though I haven't gotten consistent answers as to why. However, I cannot tell you what you are supposed to do -- I had thought that auto ref was supposed to take care of this (i.e. you could bind an rvalue to an auto ref parameter), but I've gotten mixed interpretations from Andrei on how it is supposed to work. The fact that it works with opCmp in one direction is I think a relaxation of the rules, because struct returns would be near useless if you couldn't call any methods on them. I'll leave this up to Andrei or Walter to mark it invalid, in case I'm wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
