On 2/5/13 2:21 PM, Steven Schveighoffer wrote:
On Tue, 05 Feb 2013 13:33:35 -0500, Andrei Alexandrescu
<[email protected]> wrote:
Walter and I reviewed the discussion and had a long talk. We are very
seriously considering banning the use of & against a ref result from a
function (and actually ref parameters and even struct members in @safe
code). One would still be able to take the address of a field in a
class because that's assumed to live on the GC heap.
Back to the problem I stated, how does one do this:
ref A foo();
ref A bar();
A *a;
if(condition)
a = &foo();
else
a = &bar();
// use a for a few lines
I can see a possible solution but it's not pretty:
void processA(ref A a)
{
// lines that deal with a here
}
if(condition)
processA(foo());
else
processA(bar());
But this kind of seems hacky. Why should I have to declare a function
just to keep a persistent reference to a return value for the scope of
my function? Not only is is awkward, there is a performance hit in that
I have to call another function.
You define the function in situ.
We understand some valid code will be disallowed by the change,
Note also that this doesn't fix memory issues:
struct S
{
ref S self() {return this;}
}
ref S bad()
{
S s;
return s.self();
}
Which I believe would be valid still with your rules.
Also consider the simpler:
ref int id(ref int x) { return x; }
ref int id1(ref int x) { return id(x); }
ref int id2(ref int x) { return id1(x); }
ref int oops(int x) { return id2(x); }
DIP24 addresses that and other similar cases at their core.
Andrei
