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.
