What type functions mean on a language level

[Stefan Koch]

On Saturday, 2 January 2021 at 14:34:39 UTC, sighoya wrote:
> On Saturday, 2 January 2021 at 09:13:42 UTC, Stefan Koch wrote:
>> Condition for type -> type value :
>>   you need to use a type in a place where a type value is 
>> needed.
>>
>> Conditions for type value -> type :
>>   - you need to use a type value in place where a type is 
>> needed AND
>>   - the type value needs to be a constant expression.
>>
>> correct __type__ is a basic type just like int, and therefore 
>> a keyword.
>> the reason for the four underscores it that __type is already 
>> used in the glibc binding.
>
> At first, thanks for working on first class types.
>
> Second, why we need at all __type__ and can't just reuse 
> TypeInfo?
>
> TypeInfo already gives us the opportunity to compare types for 
> equality and some other ops.
>
> We have `typeid(SecondClassType)` turning a second class type 
> into a first class type, i.e. a value we can do operations on 
> it.
>
> We just need the counterpart `asType(FirstClassType)` turning a 
> TypeInfo into an second class type back, this must be done at 
> compile time.
>
> And we need to support to call typeid at compile time.
>
> Maybe I'm wrong, just want to hear your opinion about it.
>
> I appreciate the use of first class types as they allow 
> replacing the ugly nuts of alias seqs and recursion. I think 
> executing a normal function mapping types to types could be 
> faster than macro expansion, though I don't know that exactly.

The reason I use the new primitive type __type__ is because 
typeid is meant for RTTI, and it's runtime dependent.
Whereas __type__ is a proper langauge builtin.
And therefore it can use builtin properties.
I would not be able to expose .sizeof as the .sizeof property for 
example if I used some typeinfo class.
In short the look & feel would suffer.
By using a less integrated design.