The "type" type dream

[Eric Poggel]

Nick Sabalausky wrote:
> "Michel Fortin" <michel.fortin at michelf.com> wrote in message 
> news:gghpq4$2nc6$1 at digitalmars.com...
>> 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/
>>
> 
> I love it!
> 
> 

Seconded.

What if we treat Type like a class and store all of the type specific 
meta-data as properties of it?

int a;
Type T = a.type; // or valueTypeOf(a), whatever syntax you prefer.
writefln(T.sizeof); // writes 4

Type could even have it's own set of subclasses for dealing with 
specific types of data.  We could have type info classes for Primitive, 
Struct, Class, Union, etc. that all inherit from Type.

class A {
	void foo(){}
	void bar(){}
};
A a;
Class C = a.type; // Class inherits from Type
foreach (M; C.publicMethods)
	if (M.type == A.foo.type)
		writefln(M.name); // writes "foo")

// We could also do things like this, if the stack would allow it.
a.type b = new a.type;

It's probably quite a pipe dream to be able to do this outside a 
scripting language:

void foo() { writefln("bar")};
Class C = new Class();
C.addMethod(&foo);
auto c = new C();
c.foo(); // writes "bar"

Finally, being able to work with types in this manner could eliminate 
most/all of the other competing syntaxes.  Of course, I haven't spent 
much thought on the actual implementation, which could be quite 
hard/impossible.