Idea #1 on integrating RC with GC

[Brad Anderson]

On Wednesday, 5 February 2014 at 20:18:33 UTC, Adam D. Ruppe 
wrote:
> On Wednesday, 5 February 2014 at 19:39:43 UTC, Andrei 
> Alexandrescu wrote:
>> You do figure that complicates usage considerably, right?
>
> I don't see much evidence for that. Many, many newer modules in 
> Phobos are currently allocation free yet still pretty easy to 
> use.
>
> A major source of little allocations in my code is std.conv and 
> std.string. But these aren't difficult to change to external 
> allocation, in theory at least:
>
> string s = to!string(50); // GC allocates (I'd keep this for 
> convenience and compatibility)
>
> char[16] buffer;
> char[] s = toBuffer(buffer[], 50); // same thing, using a buffer
>
> char[] s = toLowerBuffer(buffer[], "FOO");
> assert(buffer.ptr is s);
> assert(s == "foo");
>
>
> That's not hard to use (though remembering that s is a borrowed 
> reference to a stack buffer might be - escape analysis is 
> something we should really have).
>
> And it gives full control over both allocation and 
> deallocation. It'd take some changes in phobos, but so does the 
> RCSlice sooo yeah, and this actually decouples it from the GC.

Yeah, because RCSlice would require changes to Phobos too I'd 
much rather have this approach because it is just so much more 
flexible and hardly adds any inconvenience.

Combined with the upcoming allocators it would be incredibly 
powerful. You could have an output range that uses an allocator 
which stores on the stack unless it grows too big (and the stack 
size could be completely customizable by the user who knows 
best). Or you could pass in an output range that reference counts 
its memory. Or an output range that must remain unique and frees 
its contents when it goes out of scope.

I think three things would work together really well for 
addressing users that want to avoid the GC while making use of 
Phobos. 1) Increasing the support for output ranges, 2) Andrei's 
slick allocator design, and 3) @nogc. With those three I really 
think managing memory and avoiding the GC will be rather 
pleasant. @nogc would enable people trying to avoid all the tough 
to spot implicit GC allocations to identify them easily. Once 
uncovered, they just switch to the output range version of a 
function in Phobos and they then use std.allocator with the 
output range they feed in to create an ideal allocation strategy 
for their use case (whether it stack, GC, scope freed heap, 
reference counted, a memory pool, or some hybrid of those).

> The tricky part might be making it work with buffers, growable 
> buffers, sink functions, etc., but we've solved similar 
> problems with input ranges.
>
>
>> I was thinking RCSlice would be a better alternative.
>
> I very rarely care about when little slices are freed. Large 
> blocks of memory might be another story (I've used malloc+free 
> for a big internal buffer in my png.d after getting memory 
> leaks from false poitners with teh gc) but those can be handled 
> on a case by case basis. std.base64 for example might make 
> sense to return one of these animals.
>
> I don't have a problem with refcounting on principle but most 
> the time, it just doesn't matter.