I've gotten extremely close. The DPaste link that follows
demonstrates three different templates:
The first template is capable of generating the string for and
mixing in the definition of a class that has a single arbitrary
argument. An object of that class is instantiated, and its
printSelf() method is invoked to demonstrate that the arbitrary
data member it was generated with is indeed what you would expect
it to be. The magic here is fairly plain.
The second template is capable of generating the string for the
definition of a class that has some arbitrary number of arbitrary
arguments at -compile- time, through the use of variadic template
parameters. The issue with this string is that the type at T[n],
where T is the variadic template parameter, is mangled at
compile-time. The data-member-generating foreach loop shows the
three potential ways I attempted to get at the full type
information. All three have some problem with it, with typeid
giving a fully mangled type, fullyQualifiedName giving a mostly
mangled type, and __traits(identifier) giving just whatever the
alias was that was passed in. The two other commented-out code
sections in this template was an attempt to resolve the type
information at the time of mixin, rather than within the string
generation function, but this doesn't work.
The third template demonstrates that D actually can resolve the
individual types of the variadic template parameter correctly, so
long as it's allowed to do this at runtime. The string printed as
a result of instantiating this template shows exactly the class
definition we want to be able to mix in at compile time, but this
type information eludes us at compile time even though it's
clearly readily available at runtime.
The code referenced above is here: http://dpaste.dzfl.pl/a6feafc8
I'm not sure why DPaste is failing to compile the code, but I am
compiling it with DMD v2.063.2. Also included at the bottom of
the DPaste listing is the output I get when running that program,
exactly as listed.
With all of that said, there is a fundamental difference between
how the first template and the second two templates are written.
The first one, which works, resolves the T parameter during the
mixin. The second two try to resolve the variadic types during
class definition string generation. I am pretty convinced at this
point that if this is ever going to work, the variadic template
parameter type tuple needs to be resolved during the mixin, like
with the first example. The how is the question. Again, I
attempted to have the variadic template parameter types deduced
during execution of the mixin with the two blocks of
commented-out code in the second template, but I had no luck
there, as I got the same errors as I did in my previous big post.
So.
By the first template, we know that we can generate class
definitions with arbitrary data members and mix them in at
compile time using aliases for templated,
compile-time-mixin-generated classes, but for each new arbitrary
type we want the generated class to have, we need to have a
distinct template parameter for the type.
By the third template, we know that we should have access to the
fully qualified types in the variadic template parameter, but it
at least appears to only be fully resolved at runtime (which I
feel like is me misunderstanding something, but then that's also
the root of our problem).
By the second template, we show that trying to deduce the types
within the type tuple (the variadic template parameter) during
class definition string generation does not work, which leads us
to believe it must be resolved while mixing in the class
definition using the templated types, but that also doesn't seem
to work (as noted by the failed attempts in the two commented out
blocks of the second template).
I feel like we're so very close to the answer, whether it's "Oh,
you just have to do this" or "You're crazy, this is impossible."
If only it was possible to summon Andrei. He'd know! Maybe it's
some sort of a Bloody Mary thing?
Andrei, Andrei, An-
