TypeFunction example creatiing a conversion matrix

[Steven Schveighoffer]

On 10/1/20 12:49 PM, Andrei Alexandrescu wrote:
> 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), 

This is not exactly true -- the compiler still only allows strings in 
switch statements (not arbitrary types), and it also generates case 
labels based on how it expects the runtime to return the correct value. 
The runtime also expects the compiler to pass the strings in a certain 
order.

What *is* true, is that the runtime can make different decisions on what 
a match is. For example, the template could potentially do 
case-insensitive comparison, or use a different mechanism to search 
based on the incoming parameters (what it does now). But I don't know if 
this also is used in CTFE?

However, I will note that before it was this template call, the compiler 
still relied on the runtime to do what it currently does. It just passed 
the strings as a runtime parameter instead of a compile time parameter. 
(https://github.com/dlang/druntime/blob/c9dbcbb8cab8a480b143c1f8a78ba5193d3d2c40/src/rt/switch_.d#L30)

I have nothing against hoisting algorithmic tasks out of the compiler, 
and using the runtime to determine such things. In fact, I prefer it -- 
the runtime is so much more approachable as a developer than the 
compiler. But when the compiler MUST implement is(T : U), and that 
expression is well defined, I don't see why we have to reimplement that 
feature in the runtime as well. At least without a compelling example of 
"the compiler can't do this as well".

-Steve