Le 2012-04-11 à 0:56, Andrei Alexandrescu a écrit :
> On 4/10/12 11:50 PM, Jonathan M Davis wrote:
>> On Tuesday, April 10, 2012 23:33:11 Andrei Alexandrescu wrote:
>>> I think this all holds water. Destroy!
>>
>> So, this essentially erases the difference between lvalues and rvalues as far
>> as ref is concerned? ref will effectively have nothing to do with lvalues or
>> rvalues?
>
> Except when an implicit conversion is in the mix, yes. It's conversions and
> escapes that spoil things. We disallow conversion results to bind to ref and
> abolish ref escapes altogether, so I think we should be fine.
Speaking of ref escapes, perhaps it'd be a good time to remind ourselves of
this hole:
ref int foo(ref int i)
{
return i;
}
ref int bar()
{
int i;
return foo(i);
}
void main()
{
bar() += 1; // what are we incrementing again?
}
The way ref will work now makes makes it possible to define bar like this
instead, which would result in the same generated code:
ref int bar()
{
return foo(1);
}
Now the problem is a little more hidden from sight.
I don't see that as a problem of the new ref behaviour (which I like), but
since we're looking at ref semantics I thought it'd be good to have a reminder
that there's still an important hole related to ref in need of some attention.
<http://d.puremagic.com/issues/show_bug.cgi?id=3925>
--
Michel Fortin
[email protected]
http://michelf.com/
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
