On 11/26/23 00:40, Thiago Macieira via Std-Proposals wrote:

> You've only vaguely described a possible solution. We're asking you to explain
> the problem that you think this solution solves.

The OP is doing dependency injection as taught in software testing
courses.

Suppose you have to test class A in isolation, but it uses class B,
which in turn may use other classes. If you replace class B with an
interface of B, then you can supply a test mock-up of B instead of the
real B in your tests.

The problem is that the interface only exists to support testing, but
you are still paying for the virtual tables in production code.
Devirtualization may remove this cost but there is no guarantee.
I suppose that the OP is asking for such a guarantee, similar to
the guarantees given for copy elision.

The above-mentioned dependency injection is essentially the Strategy
design pattern. There are alternatives that avoids virtual tables to
begin with, such as the Mediator design pattern, or Alexandrescu's
policy-based design.