another idea for compile time functions (and a bit about type-tuples)

[Reiner Pope]

Hasan Aljudy wrote:
> I think templates is the wrong way to go for compile-time meta-programming.
Yes, templates and compile-time programming should be distinct. But the 
template programming environment and the one you describe (as far as I 
can see, const-foldable and alias-free are equivalent) are in fact 
equivalent in my opinion (see my post in 'executing pure D at 
compile-time' where I that these two things are just syntactically 
different ways of expressing the same thing).

For this reason, I think that we could relatively easily get nicer 
environment such as the one you describe, because it is trivially 
convertable to the already-working template system. Perhaps Walter could 
do it, and we would be impressed for a while.

But I don't really want that, because later we will come and look at it 
and think, 'hey, this disallows aliasing, just because we were too lazy 
back then to support a full compile-time language' and then we will feel 
stuck with a limited language, just as we now feel stuck with a limited 
template language.

Or else the Ruby, LISP, and Nemerle people will look at D and say, 'well 
we can do meta-programming with whole language; why does D (seemingly 
arbitrarily) only allow meta-programming in a limited subset?'

-----------------

I also think we should consider that the ability of the compile-time 
language to do type manipulation might not extend to runtime.

A good old type-template just means parameterising the function by type 
as well as value. Further, a type-tuple is just an array of types (it 
has .length, it has indexing, and it has basic concatenation). I think 
we should make this similarity explicit, by actually calling a 
type-tuple an array of types, giving them D's advanced array features, 
as well as allowing generic array code to be used on type-arrays.

I think the best way to do this is to unify types with TypeInfo, so that 
a template Type parameter is just a template value parameter of type 
TypeInfo, and also having the additional rule that you can do the following:

    const TypeInfo T = foo!(stuff);
    T x; // declare x as type T

This also gives us a nice symmetry between the two varargs approaches: 
they both pass TypeInfo to the function, but the old one does it at 
runtime, and the new one does it at compile time.

Furthermore, treating type-tuples as arrays allows nesting of 
type-tuples, which may occasionally be useful, and which type-tuples 
currently do not support.

Cheers,

Reiner