Proposal: First class types (at compiletime)

[Commander Zot]

On Friday, 21 July 2023 at 12:14:01 UTC, Stefan Koch wrote:
> On Friday, 21 July 2023 at 11:53:23 UTC, Commander Zot wrote:
>> On Thursday, 20 July 2023 at 21:09:40 UTC, Paul Backus wrote:
>>> On Thursday, 20 July 2023 at 17:52:38 UTC, TheGag96 wrote:
>>>> On Thursday, 20 July 2023 at 16:57:16 UTC, jmh530 wrote:
>>>>> You mean dropping it was a mistake? Or you mean type 
>>>>> functions are a mistake? (if so, can you explain more what 
>>>>> those languages had an issue with)
>>>>
>>>> Sorry, I was probably unclear - not going the type functions 
>>>> route was a mistake.
>>>
>>> The thing is, none of the existing template stuff is ever 
>>> going away. So the choice is not really between "templates" 
>>> and "first-class types", it's between "templates" and "both".
>>>
>>> I agree that, in retrospect, relying on templates for 
>>> metaprogramming was probably a mistake. But at this point, 
>>> there's nothing we can do to fix it short of starting a new 
>>> language from scratch--which is not something the D 
>>> leadership has any interest in.
>>
>> but without having them, we still have to write recursive 
>> template metaprogramming for things that would be expressed 
>> better with normal functions.
>> yes, it wouldn't remove old code, but it would be a huge win 
>> for any new code in my opinion.
>> and I remember walter mention CTFE for calculations as a huge 
>> win, so i'm really not sure if this wouldn't be either. which 
>> is the point why I bring up the topic.
>
> I can share the latest state of type-functions before I 
> abandoned the approach.
> I believe this is close to what I ended up wtih:
> https://github.com/dlang/dmd/compare/master...UplinkCoder:dmd:talias_master
> as you can see it's quite a bit of code and it leads to strange 
> interactions with the type system.
> At the time I thought that's inherent and cannot be fixed, and 
> indeed if you want to keep the same syntax that you are used to 
> using in templates, this may very well be the case.
> However if you are willing to accept changes to your code, it 
> might be possible to do something like this.

thx. but as i understand it, this is quite different then what i 
proposed, right?
my proposal doesn't implement 'type functions' as a special kind 
of function, it just uses TypeInfo as a parameter and return type.

so my idea would be to allow any type to implicitly convert to 
it's TypeInfo when a type is used in a expression.
and any TypeInfo to be converted back to it's type when assigned 
to an alias.
TypeInfo[] should be converted back to an AliasSeq of those types.