The non allocating D subset

Adam D. Ruppe destructionator at gmail.com
Sat Jun 1 13:20:55 PDT 2013


So I'm still playing with this and just realized the TypeInfos 
that are manually written in the real druntime could just as 
easily be auto-generated.

mixin(makeTypeInfo!(char[], ... more types as needed ... )());

private string makeTypeInfo(T...)() {
         if(__ctfe) { // this is here so we don't have runtime 
requirements of array append, etc, but can still use them in ctfe

         string code;
         foreach(t; T) {
                 code ~= "class TypeInfo_" ~ t.mangleof ~ " : 
TypeInfo {
                         override string toString() const { return 
\""~t.stringof~"\"; }
                 }";
         }
         return code;

         } else assert(0);
}



and so on for the other typeinfo methods. Or we could just 
copy/paste the typeinfos Walter wrote in the real druntime but 
meh.

What I'm actually doing with most these is this:

class TypeInfo_A : TypeInfo {}
class TypeInfo_i : TypeInfo {}
[etc...]


So they are pretty much useless at runtime, but the compiler 
often outputs references to them, so if we don't have the 
definition, it won't actually link.


But just thinking about runtime reflection, if we wanted to 
expand it, I say this is the way to go. Literally build the 
runtime code out of the compile time information.

Currently, you can't do something like typeid(int).isIntegral(). 
There is no isIntegral function, and adding it means doing a lot 
of boring manual stuff to add.

But with the mixin, we can just throw it in with three lines and 
be done with it.


I might actually do that here, just because I can. On a -version 
switch, of course, so you can easily opt out of the fat 
implementation.


More information about the Digitalmars-d mailing list