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