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?