Long term @nogc / allocators usage

Seb via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 24 10:04:43 PDT 2016


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

When I had to deal with this problem, I liked this idea too, but

1) Allocations with GCAllocator (e.g. makeArray) are neither 
@safe, nothrow nor pure.
2) It creates a huge template bloat

For 1) the best solution is WIP here:

https://github.com/dlang/phobos/pull/3891

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

Yep it destroys the point of @nogc, besides different data 
structures / algorithms profit from different, specialized 
allocators.

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

There are also other options [1], e.g.
- using `static if`
- using two separate functions (one with `new`)
- requiring the API user to allocate the data beforehand

[1] https://github.com/dlang/phobos/pull/4190


More information about the Digitalmars-d mailing list