Generically call a function on Variant's payload?

[Jonathan M Davis]

On Monday, August 20, 2018 8:29:30 PM MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d-learn wrote:
> 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?

Runtime reflection is theoretically possible in D, but it requires
generating the appropriate stuff for every type involved so that the runtime
stuff has something to work with. Java built all of that into the language
and has the JVM to boot, which fundamentally changes some of what can be
done. With D, we're basically in exactly the same boat as C or C++ except
that we have better compile-time type introspection. In principle, a runtime
reflection facility could be built using that, but even if it were part of
Phobos, it would still have to be opt-in. So, I don't know how useful such a
solution would ever be outside of very specific use cases. Regardless, given
that D's object files, linking, etc. are using the C tools, it was never
going to be the case that Java-style runtime reflection would be built in to
D like it is with Java.

- Jonathan M Davis