detect implicitly convertible typeid's?

[bitwise]

On Monday, 25 September 2017 at 15:12:57 UTC, Steven 
Schveighoffer wrote:
> [...]
>
> I'm not sure of how much use this is, but I do not know enough 
> to say that it's completely useless :)

> Certainly, some code somewhere has to be able to understand
> what the actual type of something is. That code may be more
> equipped to do the cast than code that doesn't know.

Type-boxing can be made much easier. The current implementation 
of Variant falls short in a few ways. Variant.coerce(T) needs the 
type at compile time, only works for certain types, and needs a 
bunch of extra code to get it done. Giving TypeInfo a 'cast' 
method seems like a more robust solution.

I've been working through a problem though, and it seesms like 
the only insurmountable issue is that Variant won't give you a 
pointer to it's contents without knowing the exact type.

I have a reflection system where you can get a collection of 
'Property' objects that represent all properties of a 
class/struct. The 'Property' returns a Variant holding the return 
value of the property function. So even though the 'Property' 
gives me a Reflection object for the return value, I still can't 
reflect on the contents of the Variant because I can't get a 
pointer to it at runtime.

Basically, I need to take a given class and recursively scan 2-3 
levels deep to find any properties/fields that are floats so they 
can be animated. The only setback right now is that Variant won't 
give me a void* to it's contents so I can reflect on it, modify 
it, and set it back in.


> A cast of builtin types is handled directly by the compiler. 
> There is no function, for instance, to cast an int to a long.
>
> A cast of a class will go through dynamic type casting.
>
> A cast of custom types will call the opCast member (or in the 
> case of implicit conversions, will use the alias this call).

I guess this makes sense. I suppose it would be dumb to resort to 
checking TypeInfo every time you needed to cast a byte to an int. 
This part of my question was not particularly well(at all) 
thought out =/

> The answer to the last is that, yes, at the moment you need a 
> custom runtime.

I really don't want to maintain a custom runtime just for this. 
It would be nice if there was a compiler flag to specify an 
RTInfo template to use. Or better yet, an attribute.

so this:

`
module source;
template MyRTInfo(T) { ... }
`
dmd source.d -rtinfo "source.MyRTInfo"


Or even better, this:

`
module reflection;
@rtinfo template RTInfo(T) { ... }

module test;
class Test{} // typeid(Test).rtinfo == reflection.RTInfo
`
dmd reflection.d test.d

So of course, dmd could complain if you specified more than one 
RTInfo either way. If two static libraries were built with 
different RTInfo's, I don't think it would technically be a 
problem since every TypeInfo would get it's own rtinfo pointer 
anyways. Maybe something in the runtime could somehow warn about 
mismatched RTInfo types like it does about cyclic module 
dependencies.