Phobos addition formal review: std.experimental.allocator

[Steven Schveighoffer via Digitalmars-d]

On 6/23/15 6:07 PM, Andrei Alexandrescu wrote:
> On 6/23/15 2:12 PM, Dicebot wrote:
>> So you have chosen worst of both worlds - neither give power users
>> ability to fine tune imports nor allow casual users always go with
>> `import std.allocator` and be happy? :)
>
> There is functionality in std.allocator to get anyone started who
> doesn't want to sit down and define their own allocator.
>
> People who want to do that can import std.allocator.building_blocks
> which is a package fully including all that's needed.
>
>> If anything, that will be the first package.d in Phobos (AFAIK) which
>> won't feature public import of _all_ package modules.
>
> I'm not afraid of creating precedent if that's the best way to go.
> Again: I have the impression we're blocked into an assumption we didn't
> take critically until now.

What happened basically was:

1. There's too much crap in some modules, it's hard to maintain, hard to 
process.
2. Let's split it up! Oh, but some people want to be able to import 
everything a la java's import java.io.*, and existing code!!!
3. package.d is the solution, just import that and it's the same thing!

I personally think that if we want to define package.d as "importing all 
the submodules", then we should stick to that. If we want to go another 
direction, we need to redo all the other splitting of modules we have 
done so far, as that is the pattern.

I'd recommend std.allocator.basic instead of std.allocator for a basic 
direction. If it doesn't make sense to import ALL of std.allocator ever, 
then drop package.d.

But you don't have to listen to me :)

-Steve