https://issues.dlang.org/show_bug.cgi?id=14612
--- Comment #3 from Kenji Hara <[email protected]> --- (In reply to Rainer Schuetze from comment #2) > The language spec says for both typeid() and .classinfo that the dynamic > type is returned. For classinfo, it says ".classinfo applied to an interface > gives the information for the interface, not the class it might be an > instance of." which makes it a compile time property for interfaces. I could > not find a spec for typeid regarding interfaces. > > I suspect they are supposed to be the same. That means typeid(i) and > i.classinfo should evaluate to typeid(I). This must be generated by the > compiler. It's correct. typeid(obj) and obj.classinfo are just same thing in implementation level. > Actually I think the semantics are pretty arbitrary and not intuitive. Why > would anyone expect J to be the correct type? I'd rather prefer if both > classes and interfaces would return the dynamic type, i.e. typeid(D). You > can get the static type of an expression by using typeid(typeof(i)). I don't know why so, but I guess it might be the dynamic cast cost. The current behavior, getting actual interface information (== classinfo) can be done with a trivial pointer (== class/interface reference) adjustment. On the other hand, a dynamic cast from interface to class needs more cost. 1. getting the interface information 2. downcast and get Object reference from the interface reference by using the information. 3. get the actual typeinfo from the Object reference. And you can do the latter behavior by typeid(cast(Object)obj). I feel that syntactic cost is enough small. In short, the orthogonality may have been priority than the intuitive, but complex behavior. --
