On Thu, Mar 28, 2019 at 4:42 AM Niall Douglas <s_sourceforge_at_[hidden]>
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