The "type" type dream

[Denis Koroskin]

On Wed, 26 Nov 2008 20:47:01 +0300, Eric Poggel <fake at example.com> wrote:

> 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;
>

C# already supports this. This is called runtime reflection:

int i = 42;
Type type = i.GetType();
Console.WriteLine(type);

Type MyTypeObject = Type.GetType(TestClass);
MemberInfo[] MyMemberArray = MyTypeObject.GetMembers();

> 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.

C# 4.0 supports this, too.