On 08/19/2011 03:04 PM, kenji hara wrote:
2011/8/19 Timon Gehr<timon.g...@gmx.ch>:
On 08/19/2011 02:16 PM, Steven Schveighoffer wrote:
On Thu, 18 Aug 2011 18:56:01 -0400, bearophile
<bearophileh...@lycos.com> wrote:
Jonathan M Davis:
I see _zero_ reason to
treat a newly constructed object as any different from one which is
returned
from a function.
I have not followed fully this thread, so I am not sure what you are
talking about, so sorry if I am misunderstanding the whole topic.
I assume you want to disallow code like:
struct Vect {
float[4] data = 0.0;
// lot of operator overloading here, all arguments are by ref
}
void foo(ref Vect f) {}
void main() {
foo(Vect([1,2,3,4]));
}
Such code is common. In foo() and in all the Vect operators ref is
required for performance. This code is quite handy. Forcing me to
define and assign a Vect to a temporary variable in main is not handy.
Think about writing expressions that use Vects with operator
overloading, that use ref everywhere. If you can't pass and give Vects
defined inside the expressions the code becomes quite more hairy.
I believe auto ref is slated to fix this problem.
-Steve
auto ref currently treats struct literals as lvalues too. (therefore, as
ref). And passing by value would be considerably less efficient for large
structs.
As I understand it, the only issue with allowing literals and function
results as lvalues is that generic code cannot detect if it is working with
a temporary or not. I don't know if this would be useful in D though.
each code segment of the form:
void foo(ref S);
...
foo(S(...));
is equivalent to one explicitly declaring the temporary:
{auto __temp=S(...); foo(__temp);}
The difference is that the first is more pleasant to write. If temporaries
would become rvalues everyone would always have to write the second form
manually. So imho it is just a syntax sugar issue.
I'd actually argue that ref-passing should work for arbitrary function
results too.
As far as I know, Andrei's original 'auto ref' means always receive
argument *by reference* either it is lvalue or rvalue, and it works
with non template function.
But, unfortunately, it doesn't exist in current D.
Kenji Hara
Oh, interesting. So why were they implemented with different semantics
then? Also, how would they work in a non-templated function? Would they
just be conservatively treated as rvalues in the function body?
