TypeFunction example creatiing a conversion matrix

[Andrei Alexandrescu]

On 10/1/20 2:08 PM, Steven Schveighoffer wrote:
> On 10/1/20 1:35 PM, Andrei Alexandrescu wrote:
>> On 10/1/20 1:26 PM, Steven Schveighoffer wrote:
>>> 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".
>>
>> How do you implement Variant.get(T) without reifying is(T : U)?
> 
> How do you implement Variant.get(T) *with* reifying is(U : T)?
> 
> step 1: determine using reified constructs that U is convertible to T
> step 2: ?????
> step 3: Return a T from a U!

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.

Nevertheless, the challenge remains - need to list the possible types a 
given type could convert to. Or in some way or another figure out 
whether T converts to U, when only one of them is available during 
compilation.

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