Bug 1348 – offTi property of TypeInfo return empty array.

The OffsetTypeInfo array returned by the offTi property of TypeInfo seems to be empty for classes that I have tried to examine. I have tested this with Tango and DMD 1.018 and 1.015 and with Phobos and DMD 2.002.

I am testing with dmd+phobos on Windows. I found that this bug is present on dmd 1.004, 1.010, and 1.020. I also found that the offTi property does not seem to exist in dmd 1.003. The OffsetTypeInfo type is also not present in that version.

Please set the version number to the oldest, not the newest, applicable. http://www.digitalmars.com/d/archives/digitalmars/D/bugs/bugzilla_usage_tips_10071.html

This appears to never have been implemented: From toobj.c in the DMD 2.040 source tree, at both 462-464 and 909-911: // offTi[] dtdword(&dt, 0); dtdword(&dt, 0); // null for now, fix later I ran into this in attempting to do runtime reflection for serialization, etc. without forcing the use if template mixins, etc.

Gide, wrong-code bugs are bugs where the assembly generated by DMD is incorrect. Not generating the offset type info isn't a wrong-code bug. Generating a bad offset typeinfo array would be.

I thought anything the compiles and does not work as defined by the spec is wrong-code, this would include outputting zeros instead of an offset.

(In reply to comment #3) > I ran into this in attempting to do runtime reflection for serialization, etc. > without forcing the use if template mixins, etc. You better start using a real programming language then, such as Scala, Vala or Go. Walter most likely disabled generation of this because it took too much space. The direction D2 is going is towards compile time reflection, and cutting down runtime reflection. (Even though compile time reflection will lead to much worse code bloat in the end, but the D designers don't know how to make sense.) This bug should probably be closed as INVALID, but leaving it open is a good way to put a little stress in Walter & Co.

nfxjfg, as noted in this bug report, this isn't a regression: D has never had any form of runtime-reflection so Walter can't have disabled it, etc. To the best of my knowledge, the shape of D's runtime reflection is still pending. Gide, you're technically right, but I feel there's a big difference in severity between, not implemented yet and silently generating incorrect code. I have added the spec keyword, because it's probably a good idea to remove the Offset type info placeholders until D's runtime-reflection strategy is defined.

It's not implemented yet, but is there as a placeholder. The shape of how introspection is best done is as yet undetermined. Hence I'll mark it as an enhancement request.

Introspection is now done at compile time. Closing this as invalid.