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.
