std.experimental.color, request reviews

[John Colvin via Digitalmars-d]

On Tuesday, 23 June 2015 at 17:11:57 UTC, Adam D. Ruppe wrote:
> 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.

Isn't this what selective imports are for? Admittedly it's not 
quite as convenient, but it does let you choose exactly what you 
want. You can even make a module that wraps a manually selected 
set of imports, e.g. you do your own basic_types module.

In the end, if you have specific requirements, you have to be 
specific.