Phobos addition formal review: std.experimental.allocator

[Andrei Alexandrescu via Digitalmars-d]

On 6/23/15 10:15 AM, Adam D. Ruppe wrote:
> On Tuesday, 23 June 2015 at 16:56:55 UTC, Andrei Alexandrescu wrote:
>> But that doesn't apply to packages that do NOT originate as big
>> modules, so they have no backward compatibility issue.
>
> My thought isn't really about backward compatibility but about
> minimizing dependencies with sibling modules.
>
> I don't want to repeat my argument too much from the other thread, but
> imagine you're writing a minimalist library that is meant to interact
> with other minimalist libraries. To interact, you want a shared
> interface and basic types. But to be minimalist, you want to pull as
> little other standard code as possible.
>
>
> The typical user might just import std.whatever and get it all
> available. But this minimalist user only wants
> std.whatever.basic_interface. If the basic interface is shoved inside
> package.d, she can't get get to it without inadvertently pulling in more
> modules too. This can quickly grow into a web of dependencies where
> importing just an interface definition ends up grabbing dozens if
> implementations you don't want too, bloating compile times and binary
> sizes.

The case with std.allocator is not everything is imported in it, so no 
bloating no nothing. -- Andrei