std.experimental.color, request reviews

[Manu via Digitalmars-d]

On 24 June 2015 at 03:11, Adam D. Ruppe via Digitalmars-d
<digitalmars-d at puremagic.com> 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.

Right, and this was what I had in mind.
I think the average user would want to: import std.color, and that's
it. They will probably want RGB8 or RGBA8.
Most users will never touch anything else in the API, so using
package.d as an "import absolutely everything" doesn't seem useful at
all to me.
Also, a use cases involving the Lab colour space almost certianly has
absolutely nothing to do with an application involving Y'UV.
I think those advanced colour space users will happily import the
package they care about.

> 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....

Well, 'half' is a bit of an exaggeration. There will be a lot more
that's not visible now, and I don't expect package.d will ever do
anything more than it does now.
I'm in favour of trimming package.d though. What do you suggest?

Will those aliases for common colour types cause a significant
compiler performance hit if they are unreferenced? Surely the compiler
won't eagerly resolve those aliases and instantiate all those colour
types in the event they are never referenced?

RGB is the common case, and it could be that that's the only one
that's present in package.d... but RGB is tricky though; it's the one
that people will almost certainly want 95% of the time, but it's also
the most complicated by far, and has the most associated detail.
I don't know how to effectively trim that for the common use case, but
I was banking on the compiler not eagerly resolving all the conversion
stuff in the event the case operator is never actually invoked?
Am I wrong about the compiler? Is it more eager than I expect?


> 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.

I was very careful to limit run-away phobos dependencies.
I really care about this, and I've tried to limit import scope in all locations.


> 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.

I think I've (deliberately) done this to the best extent I am able. If
you can suggest improvements, I'm all ears.