Long term @nogc / allocators usage

Lodovico Giaretta via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 24 08:34:55 PDT 2016


DISCLAIMER: although I've been occasionally using D for a lot of 
time, I only recently started to follow the forums and use it 
intensively, so I may miss part of the history / long term vision.

So, the current guidelines to make a function usable in @nogc are:
1) use ranges as much as possible, instead of arrays;
2) don't specify a precise delegate type, but make it templated 
(so you accept both gc and @nogc delegates);
3) use manual management (e.g. malloc/free) for internal buffers 
whose lifetime and ownership are easy to track.

Now, there are some cases in which you cannot avoid the managed 
allocations:
1) throwing exceptions: these should not be abandoned in favor of 
other solutions; IMHO, they should be easily usable in @nogc 
code; switching to error codes or user-defined callbacks is not 
feasible in general;
2) returning arrays: sometimes you just can't avoid this: if your 
function must return a string, than it has to allocate it (unless 
it's a slice of some input)

With the new allocators library, we can customize these 
allocations. There are two possible ways to follow, both with 
advantages and drawbacks:
1) have all allocating functions take a templated allocator 
parameter (defaulting to GCAllocator) and use it to allocate 
returned arrays and thrown exceptions; this allows the compiler 
to infer @nogc whenever a @nogc allocator is passed, but becomes 
bloated because you have to carry around another parameter to 
lots of functions
2) have all allocating functions use theAllocator instead of raw 
new to perform allocations. This would make the allocator 
parameter implicit and the code very easy (just set theAllocator 
on startup), but would not allow the compiler to infer @nogc; 
IMHO it's not that bad: you can always use the profiler to check 
that your code is in fact @nogc, even if not stated explicitly; 
but many will not agree with this.

So my question is: what's the plan? Which road is to be followed? 
How will Phobos evolve regarding this?


More information about the Digitalmars-d mailing list