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.
