The non allocating D subset

[adam d ruppe]

On Sunday, 9 June 2013 at 10:41:16 UTC, dam wrote:
> On Saturday, 1 June 2013 at 20:20:56 UTC, Adam D. Ruppe wrote:
>> 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.