On 4/12/12 6:40 AM, Michel Fortin wrote:
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>
I hate this problem. It makes the necessary analysis quite a bit more complicated and less precise. Essentially most functions that take a ref to a local and return a ref must be analyzed for the possibility they return the argument.
Let me look over Kenji's proposal, hopefully it takes care of this automatically :o).
Andrei _______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
