std.experimental.color, request reviews

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 24 June 2015 at 05:30:50 UTC, Manu wrote:
> 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.


Hmm, yes, that's an interesting point.

> I'm in favour of trimming package.d though. What do you suggest?

Even if it doesn't actually import everything, I'd still prefer 
to keep the package.d pretty clear. Maybe move those bits out to 
std.color.common or std.color.foundation and public import that 
from the package?


On the other hand, if everybody is ok with the package.d itself 
being a minimal import, this isn't necessary, I am just really 
worried about it growing too big in the future.


> Surely the compiler won't eagerly resolve those aliases and 
> instantiate all those colour types in the event they are never 
> referenced?

It does:

struct Foo(T) { pragma(msg, T.stringof); }
alias foo = Foo!int;

dmd test.d
int

It printed the thing meaning the template did in fact get 
instantiated when the alias mentioned it.

Templates inside the type won't be instantiated, but regular 
methods will be - along with any templates *they* reference.


In the case of the color package, this is all pretty small and 
probably not a big deal, but I'm just trying to set expectations 
that others can follow too.

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

Indeed, you did well.