TypeFunction example creatiing a conversion matrix

[Steven Schveighoffer]

On 10/1/20 2:51 PM, H. S. Teoh wrote:
> On Thu, Oct 01, 2020 at 02:28:37PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
>> On 10/1/20 2:19 PM, H. S. Teoh wrote:
> [...]
>>> We would like to be able to do this:
>>>
>>> 	Variant v;
>>> 	v = 100; // v now stores an int
>>> 	long l = v.get!long; // currently does not work
>>
>> I'm not going to respond to anything else here, but just want to point
>> out, this does work.
>>
>> https://run.dlang.io/is/S3sqDF
> 
> OK, I didn't check before I posted, :-/ but the point is that the
> implicit conversion is manually hacked with a library template that does
> not cover all the cases.  We should not have to reimplement implicit
> conversions in library code when the compiler is already perfectly
> capable of doing it.
> 
> It's not just implicit conversions, though.  There's a host of other
> things that we cannot do currently.  Like conversion to string: in
> theory, since std.conv.to is able to convert just about any type to
> string, we ought to be able to support v.get!string for *any* stored
> type.  Yet we cannot because at runtime all we have is typeid(T), so we
> cannot dispatch to the correct overload of std.conv.to to create the
> string.

It's not implicit conversions that we are talking about. It's implicit 
conversion *checks*. Actually doing the conversion requires calling a 
function, which so far has not been proposed (and I'm a little scared to 
see how big this beast is going to end up being).

And by the way, Variant.toString works... and calls the correct overload 
of to!string ;) 
https://github.com/dlang/phobos/blob/b0b64c3f41014addc6f5284f9eb20f8e90116ec2/std/variant.d#L438

"solving the Variant problem" needs a problem definition first.

-Steve