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

[Seb via Digitalmars-d]

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