On Wednesday, 4 March 2015 at 19:22:25 UTC, Zach the Mystic wrote:
On Wednesday, 4 March 2015 at 18:17:41 UTC, Andrei Alexandrescu
wrote:
Yah, this is a fork in the road: either we solve this with
DIP25 + implementation, or we add stricter static checking
disallowing two lent references to data in the same scope.
The third solution is to keep track of lifetimes, recognize
refcounted types for structs the same as suggested for classes
in DIP74, and wrap the lifetime of the subreference `t.s` in an
opAdd/Release cycle for `t`, as illustrated in my other reply.
You could have the compiler recognize a refcounted struct by
simply declaring "void opAddRef();" and "void opRelease();",
with the compiler automatically aliasing them to "this(this)"
and "~this".
I'm sorry, I just realized this proposal is too complicated, and
it wouldn't even work.
I think stricter static checking in @safe code is the way to go.
When passing a global RC type to an impure, or duplicating the
same RC reference variable in a function call, it's unsafe. The
workaround is to make copies and use them:
static RcType s; // global
RcType c;
// Instead of:
func(s);
func(c, c);
// ...do this:
auto tmp = s; // get stack reference
func(tmp);
auto d = c; // copy Rc'd type
func(c, d);
Expensive, perhaps, but safe.
