TypeFunction example creatiing a conversion matrix

[Andrei Alexandrescu]

On 10/1/20 12:12 PM, Steven Schveighoffer wrote:
> 
> The difference I see is that reification/dereification has to rebuild 
> everything that is already in the compiler, but at runtime. And it has 
> to make sure the functionality is identical. You are using the compiler 
> to build another type introspection system, but just so you can do CTFE 
> based things.
> 
> It reminds me of "modern" web applications which take over browser 
> functionality (page navigation, etc.) and reimplement it in javascript.
> 
> If we can't get a system that allows dereifcation DURING function 
> execution, then I think type functions are a much better solution. 
> There's no reason to reimplement what the compiler already does. Type 
> functions are cleaner, clearer, and much more efficient.

Hmmm... interesting. It's also been my accumulated perception that much 
metaprogramming is in fact "doing things in the target language that 
normally only the compiler writer is empowered to do". For example, the 
implementation of switch on strings has been entirely shipped to 
druntime 
(https://github.com/dlang/druntime/blob/master/src/core/internal/switch_.d), 
which does everything a compiler normally does with optimizing a switch: 
looks at the number and content of cases, defines distinct strategies 
depending on them, etc. In smaller form __cmp is the same story 
(optimizes comparison depending on the types involved) and many other 
cases. My take is that that's a good thing, because I don't need to be 
in the compiler do do powerful things.

Of course std.traits would be chock full of this kind of stuff, as no 
doubt most artifacts in there are present in the compiler internals, or 
easily extractable therefrom. In that respect, __traits is an exercise 
in "what is the minimum set of primitives the compiler needs to expose, 
in order to allow regular D code to do everything else that the compiler 
normally does?" It's a bottleneck design (complex entities communicating 
through a narrow interface). Probably not very well done because 
__traits keep on getting a variety of things that are difficult to 
decide upon. I have no good litmus test on a proposed __trait whether 
it's deserving, the right thing, the most enabling, etc. On the other 
hand, std.traits did allow us to do things that would be quite onerous 
to put in the language definition and/or compiler implementation. On the 
whole this bottleneck design has been quite enabling.

The difficulty/challenge of crossing of the barrier from types to values 
and back is good to appreciate when doing things like mixed 
compile-time/run-time uses and integration with type-oriented facilities 
(such as those in std.traits itself).