Attributes not propagating to objects via typeinfo?

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/14/15 11:39 AM, Timon Gehr wrote:
> On 08/13/2015 06:05 PM, Steven Schveighoffer wrote:
>> On 8/13/15 11:59 AM, Steven Schveighoffer wrote:
>>
>>> That is definitely a bug. It's because typeid is looking up the derived
>>> type via the vtable, but the compiler should rewrap it with 'shared'
>>> afterwards.
>>
>> Actually, now that I think about it, I'm not sure how the compiler can
>> figure this out.
>>
>> There would have to be a way to construct a TypeInfo_Shared at runtime,
>> which the compiler shouldn't be doing. Alternatively, it could
>> proactively create a TypeInfo_Shared (and all the other flavors) for
>> each class type in the runtime, and then look it up using some hash
>> mechanism.
>> ...
>
> Can't the shared typeinfo be constructed for all superclasses of C at
> the point where shared(C) is used? (Think: template instantiation.)

I don't think it can do this at compile time. It would have to do it at 
link time, since it doesn't know what subclasses of C will exist. If 
it's a dynamically-linked library, it would have to construct them on 
library load.

Optionally, it could allocate the necessary TypeInfo_Shared on the heap 
when needed. I don't like that idea either.

>
>
>> This likely isn't fixable.
>> ...
>
> I don't understand. It is evidently fixable. E.g. if TypeInfo was just a
> template without the mostly redundant additional compiler support, this
> would be a trivial fix.

I mean, it's not likely fixable without a drastic redesign of the 
typeinfo system. I'd prefer having typeinfo simply not exist as far as 
the compiler is concerned, and have typeid call a template with the type 
as the parameter. We have RTInfo, we should make the whole darned thing 
done that way.

-Steve