Idea #1 on integrating RC with GC

[Adam D. Ruppe]

On Thursday, 6 February 2014 at 00:42:20 UTC, Andrei Alexandrescu 
wrote:
> One other school of thought (to which I subscribe) is that one 
> should take advantage of reference counting where appropriate 
> within a GC milieu, regardless of more radical RC approaches 
> that may be available.

I agree with that stance, but I don't think there's a blanket 
rule there. I think RC freeing small slices will waste more time 
than it saves. Large allocations, on the other hand, might be 
worth it. So std.file.read for example returns a large block - 
that's a good candidate for refcounting since it might be 
accidentally subject to false pointers, or sit around too long 
creating needless memory pressure, etc.

(My png.d used to use large GC allocations internally and it 
ended up being problematic. I switched to malloc/free for this 
specific task and took care of that problem. But the little 
garbage created by stuff like toLower has never been a problem to 
me. (Well, except in a tight loop, but I wouldn't want to 
refcount in a tight loop either, reusing a static buffer is 
better tere.))


Anywho, I'd just go through on a case-by-case basis and tackle 
the big fish. Of course, a user could just do scope(exit) 
GC.free(ret); too.

> Yah, that does break a bunch of code. Things like the type of 
> "this" in class objects also comes to mind.

I talked about this yesterday: this should be scope too, since an 
object doesn't know its own allocation method. If the class 
object is on the stack, escaping this is wrong.. and thanks to 
emplace, it might be on the stack without the object ever 
knowing. Thus it must be conservative.

> Binding ref is also a related topic. All of these are complex 
> matters, and I think a few simple sketches don't do them 
> justice.

I'd rather discuss these details than adding RCSlice and toGC 
everywhere for more cost than benefit.

Note that working scope would also help with library RC, in 
efficiency, correctness, and ease of use.