On 06/27/2012 01:12 PM, kenji hara wrote:
2012/6/27 Timon Gehr<[email protected]>:
On 06/27/2012 07:27 AM, kenji hara wrote:
2012/6/27 Jonathan M Davis<[email protected]>:
On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:
On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
wrote:
And how would that work? auto ref duplicates the function. If
you pass it an lvalue, then it generates a ref version.
Two solutions:
- Turn 'auto ref' into 'ref', but simply have the compiler
generate a copy for the caller if he wants to pass by value?
That at least sounds like it would work. Walter may have a reason why it
doesn't though, since he's the one that said that he didn't think that it
was
possible. Maybe he just didn't think of it, or maybe it causes some other
problem that I can't think of.
After considering about 'auto ref', I was concluded that is an
inconsistency of current language spec and we cannot fix it correctly.
http://d.puremagic.com/issues/show_bug.cgi?id=8204
Therefore, I have created a thread to suggest new 'auto ref' recently.
http://forum.dlang.org/thread/cafdvkcvf6g8mc01tds6ydxqczbfp1q-a-oefvk6bgetwciu...@mail.gmail.com
Kenji Hara
How does it deal with this case?
auto ref id(auto ref arg){ return arg; }
In this case, arg might bind rvalue allocated in the caller of id, so
returning it with ref should be rejected statically.
But it is yet not implemented in pull#1019.
Kenji Hara
This is a quite severe limitation compared to how auto ref works today.
As the return ref-ness is inferred and therefore the source code must
be available, wouldn't it be a better option to decide
lvalue/rvalue-ness at the call site? The compiler would just have to
examine the first return statement in the function body.
