Problem: Cannot create class out of nothing using witchcraft

[DoctorCaptain]

On Wednesday, 16 October 2013 at 14:08:52 UTC, Benjamin Thaut 
wrote:
> Am 16.10.2013 10:40, schrieb DoctorCaptain:
>>
>> http://dpaste.dzfl.pl/07b20d75
>>
>> Note the use of typeof() to get the type of the elements at 
>> each index
>> of members, to generate a type on which a constructor can be 
>> called to
>> instantiate the elements at each index of members. Magic.
>
> There is actually a easier way to instanciate the elements. 
> Just do "new T[i]();" no need for typeof.

Thank you again for your excellent answers. I knew I shouldn't 
have posted my most recent response at two in the morning or 
whatever it was; when I woke up this morning I was thinking, "I 
understand everything I was confused about last night, and I'm 
going to look silly to the fellas that answer my questions." 
Especially, pretty much the first thing I thought of when I 
opened my eyes this morning was "I don't need to do typeof, I can 
index the type tuple, and now I look silly."

I definitely knew that the T in the mixed-in class definition is 
the same as the variadic template parameter T in our GrabBagT 
template. My question, at the time, was geared towards, "How in 
the world does it act like a tuple of types that we can just 
use?" The answer to that is, painfully obviously, T is literally 
a tuple of types that we can just use, working exactly as 
intended.

Hopefully the following is correct, as an exercise in making sure 
that my understanding is correct:

Purely theoretically speaking (as in we're no longer talking 
about D specifically, but rather "type theory" in general), let's 
take the type int[]. Variables of type int[] can be created. 
Let's do this:

int[] iarray;

For some within-bounds index i, iarray[i] will yield a -value- 
whose -type- is int.

Along these same lines (again in a go-with-me-here, theoretical 
sense), if we were to "index" the actual type int[], like int[i], 
then what is yielded at that index is the -type- int. int[] is a 
homogenous type tuple of some length, containing only the -type- 
int as an element at each of its indexes. Go with me here.

This works perfectly well. At compile time, the compiler knows 
everything it needs to know about int[] in order to reason about 
how a variable of that type, like iarray, can behave. It knows 
that at every within-bounds index of iarray, it can be sure to 
find a value of type int, because int[] is a homogenous type 
tuple of the type int.

In exactly this same way, T is also a type tuple. The only 
difference is, T can be (but by no means has to be) a 
heterogenous type tuple. That is, since we're instantiating these 
templates (that take T...) at compile time, all types contained 
within T are known at compile time, and can be reasoned about.

So let's say we declare something like:

T members;

instantiated such that myTemplate(T...) is called like 
myTemplate!(int, float, bool)

This means that, while at int[0] we can expect the -type- int, 
and at int[1] we can still expect the -type- int, at T[0] we 
expect the -type- int, at T[1] we expect the -type- float, and at 
T[2] we expect the -type- bool.

So, at members[0], we can store a -value- of type int, at 
members[1] we can store a -value- of type float, and at 
members[2], we can store a -value- of type bool.

The reason this is possible is because the compiler is aware of 
all of the types, and their order, in the type tuple T at compile 
time. The compiler can reason about the behavior of any index 
within members, because it can map that index within members back 
to the same index within T. As long as members[n] is treated as 
the type T[n], the compiler can reason about the behavior of a 
heterogenous "array" members, of type T.

Correct?

And again again again, thank you for your help.