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