The non allocating D subset

Adam D. Ruppe destructionator at gmail.com
Sat Jun 1 08:35:23 PDT 2013


BTW I think the compiler should redo array literals to work like 
this:

rewrite it into: array!T(elements....)

always try to CTFE it. Since it is a literal this should provide 
as much indication as enum that you want this.

If it works, put it out as static info in the exe.

If not just leave that call in place for the runtime to handle, 
either failing our allocating or whatever. It should be able to 
return a library type too, not necessarily a built in array type. 
e.g. it might return a HeapArrayLiteral which is incompatible 
with slice assignment, but can be assigned to a refcounted 
HeapArray. In this case, int[] a = [1,2,3]; is a compile time 
failure. Or it can return int[], whatever the lib wants.


Assoc arrays are the same thing. Rewrite it into assocarray!(K, 
V)(K[] keys, V[] values). Try to ctfe, if it works put that in 
the data segment (if possible, I guess the memory format of ctfe 
might not match.)

And if not just let the library do it.


While T[] declarations should remain just like they are now, we 
need them as a primitive building block (even if the array!() 
returns a different type), I'd change V[K] delaratiions to just 
be sugar over AssocArray!(K, V).



This would kill more typeinfo usage too while adding to 
flexibility. idk how hard it is to implement in the compiler 
though. My guess is if it were easy, Walter would have already 
done it.


More information about the Digitalmars-d mailing list