TypeFunction example creatiing a conversion matrix

[Andrei Alexandrescu]

On 10/1/20 3:08 PM, Steven Schveighoffer wrote:
> 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.

Yah, the difficulty is not execution as much as figuring out the correct 
set of types. That's where the discussion started - why redo "is" during 
compilation, turns out Variant needs kinda half of that, etc.

> 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.

And a compile-time reflection system that would allow a runtime 
reflection system would be fantastic. Unclear on where the completeness 
should stop, but this has been a D mantra for a long time now - don't 
build runtime reflection into the language because a good compile-time 
reflection can help you build any runtime reflection you want. We are 
sadly still in the early innings of that.

>>> 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.

Hmmm... do we want to eliminate a use case because it doesn't fit the 
narrative?

> FWIW, type functions can replace ImplicitConversionTargets quite easily.

A proof of concept would be helpful.