TypeFunction example creatiing a conversion matrix

[Andrei Alexandrescu]

On 10/1/20 2:40 PM, Steven Schveighoffer wrote:
> 1. Variant (a true variant that can hold ANY type) is really the only 
> use case for runtime type information.Like, literally the only.

I agree. But it's also the keystone: Any (let's call it Any...) is the 
only way to do things like creating objects and invoking functions from 
dynamically-loaded library in a sane manner. This has become clearer to 
me when I was wrestling typeid() - the right compile-time introspection 
is the kind that allows you to create runtime layouts safely.

> Algebraic types don't have to use reification *at all*.

Correct. SumType is awesome btw :o).

> Any reification 
> system is still not going to encompass all you can do with a type. Sure, 
> you can probably 100% cover type conversion. It will never 100% cover, 
> e.g. comparison or type coersion.

Coercion seems to be on the same level of difficulty as implicit 
conversions, so probably having one done right means having the other as 
well. As to what the capabilities are, it comes down to what context 
things can be dereified in (i.e. your opening post).

> 2. Compile time is the main focus here. Variant works, and can be made 
> better, and we don't have to introduce a new concept to make it work. 
> But in CTFE, pulling back the Oz curtain a bit can make things an insane 
> amount more pleasant. We don't need to reimplement what the compiler 
> does at runtime for this.

At best of course we'd have everything, and py nothing for it. One good 
question is how the quite baroque introspection facilities in std.traits 
can be helped. Things like, give me the function parameters with types 
and modifiers and attributes and all that. A struct that can be 
manipulated during compilation containing all that information would be 
very valuable.