TypeFunction example creatiing a conversion matrix

[Steven Schveighoffer]

On 10/1/20 3:33 PM, Andrei Alexandrescu wrote:
> 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.

My point is that it still needs the list in dereified form. Which you 
can't do at runtime.

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

Yeah, a full runtime reflection system would be really interesting to 
build! I don't know if it's sad that we haven't built one, or if it's 
more indicative that we don't need one.

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

It doesn't fit the scope of the problem. The problem is: I want to write 
compile-time type manipulation in a runtime style. Not that I want to do 
everything that I can do at compile time at runtime (in this case at 
*actual* runtime).

>> FWIW, type functions can replace ImplicitConversionTargets quite easily.
> 
> A proof of concept would be helpful.

I imagine the first section which is comparing just builtin types, you 
can do like:

alias[] types = [int, char, ...];
import std.algorithm : filter;
import std.array : array;
return types.filter!((alias a) => is(t : a)).array;

The other ones would be similar but use a different way to generate the 
types other than filtering a finite list.

-Steve