TypeFunction example creatiing a conversion matrix

[H. S. Teoh]

On Thu, Oct 01, 2020 at 02:08:11PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 10/1/20 1:35 PM, Andrei Alexandrescu wrote:
[...]
> > 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!
> 
> 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.
[...]

I think what Andrei is getting at is, we want to be able to transfer the
compiler's knowledge and implementation of implicit type conversions to
runtime.  I.e., we'd like to do this:

	Variant v;
	v = 100;	// v now stores an int
	...
	long l = v.get!long; // currently doesn't work

Or maybe, a more motivating example:

	T calculate(T)(Variant number) {
		T val = number.get!T;
		return val*2 + 1;
	}

	Variant v;
	v = 100;
	assert(calculate!long(v) == 201L);
	assert(calculate!float(v) == 201.0f);

I.e., you don't know what type you'd like to get from the Variant until
the caller calls you, but you also don't know what type is stored in
Variant until runtime.  Currently, there's a hack in Variant to handle
some of these implicit conversions, but as Andrei says, it's incomplete
and may have some wrong cases.  This knowledge is already in the
compiler; there should be a way to transfer this to Variant at runtime
without having to re-implement implicit conversions in library code.


T

-- 
A mathematician is a device for turning coffee into theorems. -- P. Erdos