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
