Phobos addition formal review: std.experimental.allocator

[Mike via Digitalmars-d]

On Wednesday, 24 June 2015 at 04:00:11 UTC, Andrei Alexandrescu 
wrote:
>
> std.allocator.allocator.IAllocator 
> std.allocator.allocator.theAllocator;
>
> Yep, "ridiculous" is the first thing that comes to mind.
>
> I find it difficult to digest (ehm) the fact that the same 
> community that thinks "std.allocator" is just not going to cut 
> the mustard, simultaneously believes "std.allocator.allocator" 
> is a good idea.

Of course you are right. It was indeed a poor suggestion.  But 
it's the only example I could find where a separate module name 
was used to declare the high-level API.  Perhaps it was even 
written before package.d existed.

The case against std.allocator isn't about the name, but about 
the fact that it doesn't do what people, apparently, expect: 
import the entire public API.

I count only 4 uses of package.d in official Phobos:
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/package.d
https://github.com/D-Programming-Language/phobos/blob/master/std/container/package.d
https://github.com/D-Programming-Language/phobos/blob/master/std/range/package.d
https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d

All of them seem to import the entire public API, but only 
std.algorithm.package.d is exclusively used for public imports.  
The others all have some definition of high-level API features.  
So, I don't see a precedent one way or another.  And maybe that's 
how it should be:  defined based on the intended use of the 
package.

Unfortunately, those against using package.d for the high-level 
API, did not seem to offer a suggestion for where to put your 
porcelain.  So, if you wish to accommodate them and need a name, 
consider std.allocator.api.

Mike