TypeFunction example creatiing a conversion matrix

[Steven Schveighoffer]

On 10/1/20 3:15 PM, Andrei Alexandrescu wrote:
> On 10/1/20 3:01 PM, Steven Schveighoffer wrote:
>> "solving the Variant problem" needs a problem definition first.
> 
> Problem definition: Implement Variant.get correctly. :o)
> 
> E.g. this produces a type error somewhere in the innards of std.variant: 
> https://run.dlang.io/is/joIbeV. I'm not sure how many other cases are 
> out there.

There are a lot. And you haven't even looked at contravariance:

alias F1 = void function(A);
alias F2 = void function(const(A));

F1 f1;
F2 f2;

f1 = f2; // ok

Though for some reason function(A) doesn't implicitly convert to 
function(B) (which would open this up completely to all derivative types 
in existence).

And it's not straightforward either. For instance, int can convert to 
long, but int function() cannot convert to long function().

So now you need the following properties:

canBeReturnedInsteadOf(Id)
canBeUsedAsAParameterInsteadOf(Id)

And generate all the possibilities for those (assuming they are bounded 
in one direction)

The code to make this "work" is going to be insane. And generate huge 
amounts of static data based on the type.

So let's give a more concrete definition for "implement Variant.get 
correctly". That is:

Given any two types T and U:

If this compiles:
T t;
U u = t;

Then this should as well:
Variant v = T.init;
U u = v.get!U;

The question now becomes, can we get this to work with reification 
easier or more efficiently than without reification?

I'd pose a further question: Is this important enough to add to Variant? 
I picked a typed language for a reason.

> BTW thanks Steve for choosing the right angle. This is not a contest, 
> and not a search for the proverbial nails for the use of a given hammer. 
> The converse approach is best - find what the difficult related problems 
> are, and figure how to solve them well.

I'm fine with examining multiple solutions to the problem. I'm not 
rooting for a specific solution as much as examining the tradeoffs and 
enabling mechanisms for both.

I also can't help but be biased by having used TypeInfo (which is 
essentially a less powerful Id) and seeing the limitations there.

-Steve