The "type" type dream

[Michel Fortin]

In the "Unification and extension of compile-time reflection" thread, 
Jarrett Billingsley wrote:

> static if(is(T : V[K], K, V))
> {
>    // V and K are defined here
> }

Since we're talking about unifying things...

[enter dream mode]

Imagine types as first-class values.

	static if (type V[type K] = T)
	{
		// V and K assigned from type T.
	}

Basically, we're declaring variables V and K of type "type". The "type" 
type simply holds a type. "type V[type K]" is a combined 
declaration/assignment containing the name and relative disposition of 
the two type variables to which we try to assign T. An impossible type 
assignment would assign void to both, a correct assigment would assign 
the corresponding non-void type for each variable in the specified 
position. In the if statement, void types converts to false, non-void 
types converts to true.

Now you can do all the above as separate statements if you wish (should 
make things easier to understand):

	type V; // V is void
	type K; // K is void
	V[K] = T; // compiler assign T to V and K according to the V[K] disposition.
	if (V && K) ...

Even better, type as function return type:

	type valueTypeOf(type T)
	{
		type V[type K] = T;
		return V;
	}

	static if (type V = valueTypeOf(T))
	{
		// V assigned from function valueTypeOf(T) (which returns a type).
	}

	valueTypeOf(T) a; // variable of the type returned by valueTypeOf(T).

Here, valueTypeOf is a function taking a type as argument and returning 
another type. Obviously, it's a function that can only be evaluated at 
compile-time, but with it we can just forget about using templates and 
declarative programming when we need to create variables of related 
types.

[exit dream mode]

Not sure what all this would entail, but if we could return types from 
functions, would we still need templates at all? Couldn't we just 
create any struct or class inside the function and return that? 
Unifying templates and functions... hum, I'm probably still dreaming.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/