Phobos addition formal review: std.experimental.allocator

[Andrei Alexandrescu via Digitalmars-d]

On 6/23/15 2:18 AM, Dicebot wrote:
> On Monday, 22 June 2015 at 22:38:19 UTC, Andrei Alexandrescu wrote:
>> Perhaps I misunderstood the request - currently the imports in
>> allocator/package.d are:
>>
>> public import std.experimental.allocator.common,
>> std.experimental.allocator.typed; import std.algorithm, std.conv,
>> std.exception, std.range, std.traits, std.typecons, std.typetuple;
>> version(unittest) import std.random, std.stdio;
>>
>> Is that okay, and if not what should change?
>
> My concern was about the fact that symbols `IAllocator`,
> `theAllocator`, `processAllocator` and bunch of others are defined
> within `package.d` itself and not provided via public import. That
> means that anyone willing to change default allocator or use `make`
> MUST import all std.allocator modules even if nothing else is really
> needed (those utilities look very independent). Which means
> processing bunch of unnecessary imports - and more of those if more
> modules will get added to the package.
>
> I'd prefer to have a small dedicated module, i.e. `std.allocator.api`
>  (not going to discuss names!) and do public import of it from
> `std.allocator.package.d`. Makes sense?

I see. Well this raises the question whether importing std.xyz
automatically means everything under std.xyz is transitorily imported. 
Right now it's not - the more advanced/obscure building blocks are not 
automatically imported if you just import std.allocator; for those you'd 
need to import the std.allocator.building_blocks package, or individual 
modules from it like std.allocator.building_blocks.region.

This idea was proposed by Mike on 2015/05/18:

> Would it be better to move the porcelain code into package.d so the
> nomenclature simply becomes `import std.allocator;`?

I liked the idea that someone who's not an expert goes "let me import 
std.allocator and call it a day" whereas someone who wants to tweak, 
customize, etc. they'd need to be more specific.

If we define an entry point such as "std.allocator.api", novices will 
have one more thing to remember, or some will still import 
"std.allocator" thus pulling everything without realizing it.

So I'd say let's keep simple things simple. If you want to allocate, 
import std.allocator.


Andrei