Phobos addition formal review: std.experimental.allocator

[Adam D. Ruppe via Digitalmars-d]

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.