Long term @nogc / allocators usage

[ZombineDev via Digitalmars-d]

On Sunday, 24 July 2016 at 17:04:43 UTC, Seb wrote:
> 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

I prefer alias template parameters as they provide maximum 
flexibility:
https://github.com/dlang/phobos/pull/4288#issuecomment-227609141