detect implicitly convertible typeid's?

[Steven Schveighoffer]

On 9/25/17 10:43 AM, bitwise wrote:
> On Monday, 25 September 2017 at 13:20:03 UTC, Steven Schveighoffer wrote:
>> On 9/23/17 11:52 AM, bitwise wrote:
>>> Is it possible to tell if two objects represented by TypeInfo's are 
>>> convertible to each other?
>>>
>>> Basically, is there a built in way to do this?
>>>
>>> int x;
>>> long y;
>>> assert(typeid(x).isImplicitlyConvertibleTo(typeid(y));
>>
>> I would say no. There isn't any function/data to detect that.
>>
>> Keep in mind that TypeInfo is generated by the compiler, and only 
>> contains what the developers of the runtime have wanted it to contain. 
>> It's not a full-fledged reflection system.
> 
> Something like this along side TypeInfo.postblit and TypeInfo.destroy 
> would actually be useful:
> 
> TypeInfo.cast(void* src, void** dst, TypeInfo dstType);

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.

> I wonder though...does a cast even resolve to a single function call at 
> compile time, or is there scattered context-dependent code throughout 
> the compiler to insert the appropriate logic?

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

> Based on current trends though, it seems like TypeInfo.postblit/destroy 
> may be on the chopping block...any idea?

Hm... I don't know, but I would guess that almost everything in TypeInfo 
is on the chopping block. If we could replace AA implementation with 
something that is entirely library based, we wouldn't need most of that 
stuff.

>> However, you COULD build something in RTInfo that could place that 
>> inside the TypeInfo. That is what RTInfo was added for.
> 
> The comments say it's for precise GC:
> 
> https://github.com/dlang/druntime/blob/cc8edc611fa1d753ebb6a5fabbc3f37d8564bda3/src/object.d#L312-L314 

The reason it was added was to allow development of a precise GC without 
having to muck with the compiler. Essentially it is instantiated once 
per type and the result added to the TypeInfo by the compiler. Precise 
GC is one possibility for that, but it can be used for anything.

> Doesn't that mean my code could some day get clobbered if I put it there 
> and precise GC is implemented?
> 
> Also, don't I need to compile a custom runtime for that?

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

The answer to the first is that you need a custom runtime anyway, so you 
don't have to worry about clobbering :)

I would say that once we DO need RTInfo for something (right now it is 
unused), we need to consider options for how to make it available for 
multiple things at once.

-Steve