Attributes not propagating to objects via typeinfo?

Steven Schveighoffer via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Aug 14 05:36:28 PDT 2015


On 8/14/15 4:22 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>" 
wrote:
> On Thursday, 13 August 2015 at 16:05:19 UTC, 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.
>>
>> This likely isn't fixable.
>>
>> What you CAN do, however, is:
>>
>> typeid(typeof(c))
>>
>> Which should get the *static* type (and that should be TypeInfo_Shared
>> in both struct and class instances).
>>
>> So likely this is not a bug, or at the best, a wontfix.
>
> If it yields invalid results, it should at least be forbidden, if it
> can't be fixed.

I think it's really a limitation of the runtime. If we can eliminate 
TypeInfo from the purview of the compiler, we could do some kind of 
solution where the result of typeid could be some sort of wrapper struct 
in this case.

But I don't know if it's a good idea to forbid this, you would probably 
break a lot of code.

-Steve


More information about the Digitalmars-d-learn mailing list