Improving DIP74: functions borrow by default, retain only if needed

[Zach the Mystic via Digitalmars-d]

On Friday, 27 February 2015 at 18:24:27 UTC, Andrei Alexandrescu 
wrote:
> DIP74's function call protocol for RCOs has the caller insert 
> opAddRef for each RCO passed by value. Then the callee has the 
> responsibility to call opRelease (or defer that to another 
> entity). This choice of protocol mimics the 
> constructor/destructor protocol and probably shows our C++ bias.
>
> However, ARC does not do that. Instead, it implicitly assumes 
> the callee is a borrower of the reference. Only if the callee 
> wants to copy the parameter to a member or a global (i.e. save 
> it beyond the duration of the call), a new call to retain() (= 
> opAddRef) is inserted. That way, functions that only need to 
> look at the object but not store it incur no reference call 
> overhead.
>
> So I was thinking of changing DIP74 as follows:
>
> * Caller does NOT insert an opAddRef for byval RCOs
>
> * Callee does NOT insert an opRelease for its byval RCO 
> parameters
>
> It seems everything will just work with this change (including 
> all move scenarios), but it is simple enough to make me worry 
> I'm missing something. Thoughts?

I think it's fine. I couldn't even figure out the original motive 
for wanting to add those calls -- I thought it must have 
something to do with threads or exceptions or something, but even 
then I couldn't figure it out. Any reference argument will, by 
definition, outlive its function -- it can't possibly die within 
the function itself, since the caller still thinks it's a valid 
reference.

Another thing is that local references in general need not 
participate in reference counting. They will retain and release 
the reference automatically when they go in and out of scope. I'm 
really no expert (except that I like to study and think and by 
thinking become somewhat expert it appears), but if all ARC could 
be confined to global/heap <=> global/heap copies, you'd get the 
most efficient code. And I'm not trying to advertise a reference 
tracking system :-), but the real hiccup is that global reference 
can go *through* the stack and land back at a global... and you 
would need to keep track of that.