std.experimental.color, request reviews

[Adam D. Ruppe via Digitalmars-d]

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.