Proposal: First class types (at compiletime)

[Commander Zot]

On Friday, 21 July 2023 at 09:03:15 UTC, Quirin Schroll wrote:
> On Friday, 21 July 2023 at 08:52:47 UTC, Quirin Schroll wrote:
>> On Thursday, 20 July 2023 at 13:44:15 UTC, Commander Zot wrote:
>>> wouldn't it be possible to have something like first class 
>>> types (at compile time) to replace tamplates for type logic 
>>> with regular functions executed at CTFE?
>>
>> Of course, that’s possible. You’d have a type called `Type` 
>> that represents types. Of course, `Type` does not actually 
>> exist, a function that takes `Type` parameters or returns 
>> `Type` cannot end up in the object file. But for CTFE, the 
>> compiler can pretend that `Type` is just a type like `Object`.
>>
>> […]
>
> Note that, in my understanding of “first-class,” this isn’t 
> actually first-class types. You still have transformations. 
> `Type` is a first-class type, and `Type` objects are 
> first-class objects – at least in CTFE –, but types (as per D 
> grammar) are not first-class things.
>
> If you had first-class types, you could do something like:
> ```d
> Type[] sort(Type[] types) { … }
> auto Integers = sort(int, long, short);
> Integers[0] little;
> Integers[1] middle;
> Integers[2] large;
> ```
> I guess parsing any expression as a type is out of reach and 
> thus first-class types are as well.

that's why i thought first-class only at compiletime.
in your example 'auto Integers' would be a runtime variable, and 
while this could be made to work, i don't think it's that useful.

```d
  Type[] sort(Type[] types...) { … }
  alias Integers = sort(int, long, short);
  Integers[0] little;
  Integers[1] middle;
  Integers[2] large;
```

this should work. however. assigning a Type to an alias would 
have to make it a real type again. assigning a Type[] to an alias 
should make it an AliasSeq of types.