Long term @nogc / allocators usage

[Dicebot via Digitalmars-d]

@nogc code is quite different from idiomatic "casual" D code and 
one is expected to make sacrifices to go for it. Here are some 
approaches I decided for myself:

On Sunday, 24 July 2016 at 15:34:55 UTC, Lodovico Giaretta wrote:
> 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;

Use pre-allocated exception instances. Throwing itself doesn't 
require GC, only allocating exception does. You can possibly 
screw up exception chaining this way but this is a very minor 
loss.

> 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)

If it can't be avoided, this is not @nogc code and there is no 
point in pretending otherwise. Use ranges and sinks instead to 
move allocations decisions up the call chain. Note that with sink 
approach you want be able to mark function itself @nogc (because 
sink delegate allocates) but you can mark unittest block that 
verifies there are no _other_ allocations:

void foo ( alias sink_dg ) ( )
{
     sink_dg("abc");
}

@nogc unittest
{
     void noop_sink ( const(char)[] chunk ) @nogc { }
     foo!noop_sink();
}