std.experimental.color, request reviews

[Manu via Digitalmars-d]

On 25 June 2015 at 05:59, Adam D. Ruppe via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.

Bugger! So an instantiation of the struct is one thing, will it also
instantiate all the members and functions too? If it leads to an
instantiation of the cast operator, then at that point, that's
basically everything... the whole library is pulled.

What selective imports? Do selective imports of a single symbol from a
module lead to the whole module being parsed and top level
instantiations?


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

Regular methods will be, but not template methods?
Good, that means the cast operator will not be instantiated until it
is referenced. This is critical, that's the point that leads to
basically everything.
Ideally conv.d would only have selective imports at the top (if
there's an advantage to that) and proper imports scoped within the
various cast functions. Would that be a win, or will the selective
imports from each module at the top negate the advantage?


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