title: Why is std::type_info polymorphic?
body: <p>Is there a reason why <code>std::type_info</code> is specified to be polymorphic? The destructor is specified to be virtual (and there's a comment to the effect of "so that it's polymorphic" in The Design and Evolution of C++). I can't really see a compelling reason why. I don't have any specific use case, I was just wondering if there ever was a rationale or story behind it.</p>
  
  <hr>
  
  <p>Here's some ideas that I've come up with and rejected:</p>
  
  <ol>
  <li>It's an extensibility point - implementations might define subclasses, and programs might then try to <code>dynamic_cast</code> a <code>std::type_info</code> to another, implementation-defined derived type. This is possibly the reason, but it seems that it's just as easy for implementations to add an implementation-defined member, which could possibly be virtual. Programs wishing to test for these extensions would necessarily be non-portable anyway.</li>
  <li>It's to ensure that derived types are destroyed properly when <code>delete</code>ing a base pointer. But there are no standard derived types, users can't define useful derived types, because <code>type_info</code> has no standard public constructors, and so <code>delete</code>ing a <code>type_info</code> pointer is never both legal and portable. And the derived types aren't useful because they can't be constructed - the only use I know for such non-constructible derived types is in the implementation of things like the <code>is_polymorphic</code> type trait.</li>
  <li>It leaves open the possibility of metaclasses with customized types - each real polymorphic <code>class A</code> would get a derived "metaclass" <code>A__type_info</code>, which derives from <code>type_info</code>. Perhaps such derived classes could expose members that call <code>new A</code> with various constructor arguments in a type-safe way, and things like that. But making <code>type_info</code> polymorphic itself actually makes such an idea basically impossible to implement, because you'd have to have metaclasses for your metaclasses, ad infinitum, which is a problem if all the <code>type_info</code> objects have static storage duration. Maybe barring this is the reason for making it polymorphic.</li>
  <li>There's some use for applying RTTI features (other than <code>dynamic_cast</code>) to <code>std::type_info</code> itself, or someone thought that it was cute, or embarrassing if <code>type_info</code> wasn't polymorphic. But given that there's no standard derived type, and no other classes in the standard hierarchy which one might reasonably try cross-cast to, the question is: what? Is there a use for expressions such as <code>typeid(std::type_info) == typeid(typeid(A))</code>?</li>
  <li>It's because implementers will create their own private derived type (as I believe GCC does). But, why bother specifying it? Even if the destructor wasn't specified as virtual and an implementer decided that it should be, surely that implementation could declare it virtual, because it doesn't change the set of allowed operations on <code>type_info</code>, so a portable program wouldn't be able to tell the difference.</li>
  <li>It's something to do with compilers with partially compatible ABIs coexisting, possibly as a result of dynamic linking. Perhaps implementers could recognize their own <code>type_info</code> subclass (as opposed to one originating from another vendor) in a portable way if <code>type_info</code> was guaranteed to be virtual.</li>
  </ol>
  
  <p>The last one is the most plausible to me at the moment, but it's pretty weak.</p>