TypeFunction example creatiing a conversion matrix

[Steven Schveighoffer]

On 10/1/20 2:30 PM, Andrei Alexandrescu wrote:

> The mechanics of carrying the conversion are also needed, especially if 
> a change in format is necessary (e.g. int to long or float to double). 
> It looks like a pointer to function needs to be part of the solution.

Yes, Variant already does this. And it does this by a static unrolled 
loop over the actual types. Not the reified types.

So you'd have to build that mechanism into reification to "replace" 
Variant's usage of ImplicitConversionTargets. In other words, you can't 
just hoist this one piece into reification. You need to hoist ALL OF IT.

At some point, you are going to end up with a complete runtime 
reflection system.

> 
>> BTW, Variant already does a *limited* form of this. reification 
>> doesn't change what needs to happen.
>>
>> I don't see why Variant's needs have to dictate how you need to reason 
>> about types at compile time in CTFE.
> 
> The more applicability to difficult problems a mechanism has, the more 
> useful it is. Looking good on cherry-picked examples is not enough. 
> Difficult related problems that we have are introspection, std.meta, 
> std.traits, and std.variant. The latter can be considered a problem of 
> having the right primitives in std.traits.

Variant already has a solution. And it's tailored to Variant. I do not 
consider *at all* the problems Variant has to be related to a nicer 
compile time usage of types inside CTFE.

FWIW, type functions can replace ImplicitConversionTargets quite easily.

-Steve