ETA: std.experimental.allocator -> std.allocator

December 10, 2016
Posted by Seb
Permalink
Seb
Permalink
Hi all,

tl;dr: I would like to start having GC-free methods and data structures in Phobos, which depends on std.allocator being stable (i.e not in experimental).
Q1: So I would like to know what's missing/blocking this? Is it just time?
(FYI: std.experimental.allocator has been merged in October 2015 and released in November 2015 with 2.069)

One thing that I heard a bit is that there's no defined guideline on how Allocator APIs should look like. I have seen two good patterns so far that, but they both have their pros/cons. As I think this is very important when std.allocator will be used in Phobos I summarized them below to help everyone to get into the discussion.
Q2: What is your favorite Allocator API pattern and how should Phobos APIs facilitate opt-in GC-free algorithms/data structures?

Q3: Are there any plans on providing language support for custom allocators? E.g.

new int[10] -> theAllocator.makeArray
new FancyClass(foo) -> theAllocator.make!FancyClass(foo)


1) Allocator with GCAllocator as default argument
-------------------------------------------------

I think that's how most people use the Allocator. A prominent example is the EMSI's container library [1].
The basic idea is that by default all allocations are handled conveniently by the GCAllocator.

import std.experimental.allocator.gc_allocator: GCAllocator;

void myFun(Allocator = shared GCAllocator)(int foo, ref Allocator alloc = Allocator.instance)
{
    import std.experimental.allocator : makeArray, dispose;
    auto b = alloc.makeArray!int(10); // instead of new int[10]
    alloc.dispose(b);
}

unittest
{
    myFun(2);
    import std.experimental.allocator.mallocator: Mallocator;
    myFun(2, Mallocator.instance);
}

Please note that although since 2.072 for make/makeArray attributes are automatically propagated, due to the global sharedness of the GCAllocator such templated code can't be @safe (see e.g. [2] for a discussion).

2) makeX pattern
----------------

The idea here is to provide a special makeX method that allows the use of custom allocator.
This pattern is intended for cases in which allocated data is returned to the user.

A simplified example from Phobos:

auto slice(T, size_t N)(size_t[N] lengths...);
SliceAllocationResult!(N, T) makeSlice(T, Allocator, size_t N)(auto ref Allocator alloc, size_t[N] lengths...);

And a short usage example:

slice!int(2, 3);
Mallocator.instance.makeSlice!int(2, 3);

Another good example is mir.combinatorics [2].

The idea here is that it's the users job to deal with the allocated data, he has to call dispose himself. Thus a convenience dispose overload may be provided.

[1] https://github.com/economicmodeling/containers
[2] https://github.com/dlang/phobos/pull/4288
[3] http://dlang.org/phobos/std_experimental_ndslice_slice.html#.ndarray
[4] http://docs.mir.dlang.io/latest/mir_combinatorics.html
Forums
