Should classes explicitly declare whether they have a vptr?

[jonmeow]

Summary of issue:

Right now, whether a class's object representation includes a vptr is implicit from the presence of virtual functions. Should it be explicitly declared?

Details:

A base class may or may not have a virtual function. Similarly, an abstract class may not have abstract functions. As a consequence, we don't really know whether a vptr is present in a type's object representation until the class is complete.

Regarding syntax, we would probably want things to indicate both base and abstract classes with-and-without vptrs. When inheriting, extend base is probably sufficient to infer from the parent. So this is probably mostly a question about whether the incremental overhead of a vptr should be explicit for developer control, or implicit for consistency with C++.

Any other information that you want to share?

In discussion of alternatives, the main advantage to having non-virtual inheritance over planned alternatives (such as mixins) is the ability to down-cast.

Note while Carbon supports an abstract class with no abstract functions, that's a feature on top of C++.

In the toolchain, we're planning on handling the current design by lazily calculating element indices after the class is complete. This may have some edge-case behaviors still, because it's possible to have references to members (e.g. in C++, auto F() -> decltype(my_member_)) but the index shouldn't matter in those cases. So either way seems to be manageable in the toolchain.

[zygoloid]

Explicit vptr syntax would give us (at least) one additional feature beyond those in C++: a class could have a vptr with no virtual functions (similar to how we allow a class to be abstract with no abstract functions). This is occasionally desired in C++ to allow dynamic_cast without other polymorphism.

[chandlerc]

Would it also help with homing of the vtable? I guess that's probably fixed by us always emitting a .o file for the API file.