On 1 March 2015 at 18:57, Matthias Bentrup via Digitalmars-d <[email protected]> wrote: > On Sunday, 1 March 2015 at 07:04:09 UTC, Zach the Mystic wrote: >> >> On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei Alexandrescu wrote: >>> >>> Defines a significantly better function call protocol: >>> >>> http://wiki.dlang.org/DIP74 >>> >>> Andrei >> >> >> This is obviously much better, Andrei. >> >> I think an alternative solution (I know -- another idea -- against my own >> first idea!) is to keep track of this from the caller's side. The compiler, >> in this case, when copying a ref-counted type (or derivative) into a >> parameter, would actually check to see if it's splitting the variable in >> two. Look at this: >> >> class RcType {...} >> >> void fun(RcType1 c, RcType1 d); >> >> auto x = new RcType; >> >> fun(x, x); >> >> If the compiler were smart, it would realize that by splitting parameters >> this way, it's actually adding an additional reference to x. The function >> should get one x for free, and then force an opAdd/opRelease, for every >> additional x (or x derivative) it detects in the same call. >> >> This might be even better than the improved current proposal. The real key >> is realizing that duplicating an lvalue into the same function call is >> subtly adding a new reference to it. >> >> Eh?? > > > Note that you can get the same issue without duplicate parameters, if you > pass an alias to a global variable. > > > static A a; > > void fun(A x) { > a = null; // Releases x > x.func(); > } > > void main() { > a = new A(); > fun(a); > }
Thing here is that 'a' does not belong to main(). There must be a reference on the caller's stack for it to be passed to a non-pure function. If a function X passes a value it does not own to some other function, then X needs to increment the refcount such that it holds one reference for itself. For the callee, it received via an argument, so it has confidence a stack reference exists, and it doesn't need to bump anymore down the call tree.
