2398. type_info's destructor shouldn't be required to be virtual

Section: 17.7.3 [type.info] Status: Open Submitter: Stephan T. Lavavej Opened: 2014-06-14 Last modified: 2016-08-06

Priority: 3

View all other issues in [type.info].

View all issues with Open status.

Discussion:

type_info's destructor is depicted as being virtual, which is nearly unobservable to users (since they can't construct or copy this class, they can't usefully derive from it). However, it's technically observable (via is_polymorphic and has_virtual_destructor). It also imposes real costs on implementations, requiring them to store one vptr per type_info object, when RTTI space consumption is a significant concern.

Making this implementation-defined wouldn't affect users (who can observe this only if they're specifically looking for it) and wouldn't affect implementations who need virtual here, but it would allow other implementations to drop virtual and improve their RTTI space consumption.

Richard Smith:

It's observable in a few other ways.

std::map<void*, something> m;
m[dynamic_cast<void*>(&typeid(blah))] = stuff;

... is broken by this change, because you can't dynamic_cast a non-polymorphic class type to void*.

type_info& f();
typeid(f());

... evaluates f() at runtime without this change, and might not do so with this change.

These are probably rare things, but I can imagine at least some forms of the latter being used in SFINAE tricks.

[Lenexa 2015-05-05: Move to Open]

Marshall to poll LEWG for their opinion

[2016-06]

On the reflector, STL wrote:

We'll prototype this change and report back with data in the future.

[2016-08 Chicago]

No update from STL. Set priority to P3

Proposed resolution:

This wording is relative to N3936.

  1. Change 17.7.3 [type.info] as indicated:

    namespace std {
      class type_info {
      public:
        virtualsee below ~type_info();
        […]
      };
    }
    

    -1- The class type_info describes type information generated by the implementation. Objects of this class effectively store a pointer to a name for the type, and an encoded value suitable for comparing two types for equality or collating order. The names, encoding rule, and collating sequence for types are all unspecified and may differ between programs. Whether ~type_info() is virtual is implementation-defined.