Problem: Cannot create class out of nothing using witchcraft

[Benjamin Thaut]

Am 16.10.2013 21:02, schrieb 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.

I never had type theory in university, but your explanation sounds 
reasonable and correct ;-)

Kind Regards
Benjamin Thaut