On Thu, Mar 28, 2019 at 4:42 AM Niall Douglas <s_sourceforge@nedprod.com> wrote:

<snip>,
For me personally, I think that the time has come for vptr-based "plain"
virtual function dispatch to be anointed as THE implementation. Then we
can expand the category of bit copyable types significantly, to the
great long term benefit of the ecosystem.

Just to be clear, by this I specifically mean the most common case of
there being a single vptr to a single vtable containing all the virtual
function implementations for that type.

I do not mean the situation where there are virtual base classes, which
is usually implemented by adding a second vbptr or second (or third) vptr.

I appreciate that this will not be a popular opinion. However, single
vptr types are C-compatible, and I think it might be possible to
persuade WG14 to have C support the "plain" vptr-based dispatch. We then
can draw a line around that as "C support". This would be in keeping
with closer C and C++ cooperation on Herbceptions, as well.

At the most recent CppCon, there was a community meeting on "virtual polymorphism" (e.g., runtime polymorphic dispatch), such as through a vptr/vtable.

Motivation: It was observed that the community is increasingly tending towards compile-time polymorphism (through templates) versus historical interest in runtime polymorphism (through vptr/vtable), for designs that want to avoid the double-indirection at runtime.

Gašper Ažman made a comment that it would require language support to most properly isolate vptr/vtable machinery to be separately composable from the class definition. It would be good to get him to comment further on what language changes might be required, and our options here.

IMHO, if we follow Niall's thoughts here, it might be good to address both issues at the same time:

(a) Separately composable runtime polymorphism in C++

(b) C and C++ compatibility for (significantly) more design patterns

I am sympathetic to this, and sympathetic to changing the language (both C and C++, I use both daily). This seems to address complaints such as:

(1) C++ designs tending towards "the base class of Evil" (is an anti-pattern)

(2) We are all writing our own composable vptr dispatch mechanisms (through a variety of well-known patterns), but in incompatible ways that are problematic for composing systems with 3rd party libraries.

The #dynamic_polymorphism channel under the Cpplang slack was created after CppCon for this discussion, but it's mostly dead (no discussion).

--charley