On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:
But that's more an argument against putting anything _except_
the basic definitions into package.d, no? Then you can always
exclude the more specific stuff whenever you need it, and those
modules themselves can publicly import package.d.
What if you want the basic definitions alone to build something
off of?
If I want to write an image library that can share pixels with
your image library, I might import std.color just to get the
pixel format. I don't need the list of colors nor any algorithms,
I just want to share the basic type so our two libraries can pass
data back and forth.
So I write like
RGBA8[] readImage() {}
With the std.color functions, some other library can now take
that pixel array and convert it or whatever they need to do.
Great, you can use my thing pretty easily.
But I don't need any conversions myself. I don't do
transformations. I don't use named colors, blending functions, or
anything else. (Maybe my image format is extremely simple.)
So pulling the rest of the library would waste compile time and
binary space. Especially if a user wanted my extremely simple
image format exactly because they were short on time and space.
So ideally, my module would ONLY import std.color.basic_types or
something like that.... but alas, RGBA8 is defined in package.d,
so if I want it, whether I like it or not, I just pulled half the
std.color library....
which just pulled std.traits and std.typecons, which, thankfully,
didn't import anything else, but that's not the case for so many
Phobos modules.
This layout isn't bad today, the std.color in the PR is pretty
small and pretty lazy thanks to the templates and local imports
in them, but I still want to set a precedent in Phobos of
untangling the web of dependencies by moving as much independent
code as reasonably possible to independent modules.