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.
