On 08/20/2018 04:34 PM, Jonathan M Davis wrote:
foreach(T; TypesThatVariantHolds)
Yea, that's what I would've just done, but I wanted to support
user-created types not already known to my library.
You
can't just call functions on completely unknown types, because the compiler
wouldn't know what code to generate or what to link against.
Right. D's templates have really spoiled me. Because of them, I've grown
accustomed to invoking functions on unknown types ;)
But you're right, that's not going to work for runtime dispatch without
enumerating each possible type. Even if I try (like I was thinking) to
provide a templated function to convert any of the concrete types to an
internal-only supertype, I'd still need something to runtime dispatch to
the right template instance. Darn.
A lot of times, I really wish I could introspect across *all* linked
modules, not just specific ones. Ex: "Hey compiler, give me a
compile-time list of ALL types in this program with UDA @xyz". Then
things like this could be built out of that. No need to worry about
unknown types/symbols because they would all be known and a finite list
could always be constructed.
Although, what would REALLY be nice is if, for every type, the compiler
built a list of every member and how to access it (which...really it has
to do anyway), but then uses that info to build a master runtime
dispatch system. Types such as Variant already have runtime knowledge of
what type is currently being held, so that info could be passed to the
compiler-generated "master runtime dispatch" system along with what
member to invoke/access.
Come to think of it...aren't I just describing standard run-of-the-mill
runtime reflection? I mean, hasn't Java already been able to do that for
ages? But then, in Java everything is already part of the class
hierarchy anyway so maybe that's why it's possible there?
