Phobos addition formal review: std.experimental.allocator

[extrawurst via Digitalmars-d]

On Tuesday, 23 June 2015 at 15:56:15 UTC, Andrei Alexandrescu 
wrote:
> 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

I agree with Adam on this: "Just a quick concern, I don't think a 
package.d should ever have anything except imports in it"
(see 
http://forum.dlang.org/post/qwatonmpnoyjsvzjpyjl@forum.dlang.org)

for convenience the package.d could still import a bunch of 
default stuff publicly for the "normal" user.