On Sunday, 1 March 2015 at 19:22:06 UTC, Walter Bright wrote:
On 3/1/2015 7:44 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
<[email protected]>" wrote:
A weakness of the same kind affects DIP25, too. The core of
the problem is
borrowing (ref return as in DIP25), combined with manual
(albeit hidden) memory
management. An example to illustrate:
struct T {
void doSomething();
}
struct S {
RCArray!T array;
}
void main() {
auto s = S(RCArray!T([T()])); // s.array's refcount is
now 1
foo(s, s.array[0]); // pass by ref
}
void foo(ref S s, ref T T) {
s.array = RCArray!T([]); // drop the old s.array
t.doSomething(); // oops, t is gone
}
The trouble seems to happen when there are two references to
the same object passed to a function. I.e. there can be only
one "borrowed" ref at a time.
I'm thinking this could be statically disallowed in @safe code.
Yes, it's a classical aliasing problem. Of course, if the
references can't possible alias because of their types, it's ok.
However, for non-pure functions, it's always (?) unsafe, because
they have access to all kinds of global variables. Too bad we
don't have pure by default :-(
