Arthur, I think you may be misremembering something. Under no circumstances should the language implicitly generate multiple invocations of the destructor on a single virtual base subobject, and the destruction order is completely specified by the standard - it is the reverse of construction order, which is well-defined ([class.dtor]/9, [class.base.init]/13.1). What you might be recalling is that implicitly defined assignment operators may assign virtual base class subobjects more than once.

I agree that contacting the authors of P0784 is a good idea, however, I think the most likely explanation for why the changes in P0784 include the prohibition on virtual base classes is that that prohibition already exists in the rules for constexpr constructors ([dcl.constexpr]/4.1) and that the authors simply didn't feel like analyzing the consequences of changing it at this time.

On Mon, Jun 10, 2019 at 7:52 AM Arthur O'Dwyer via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Hi Lyberta,

My kneejerk reaction was "of course virtual bases should be supported in constexpr, if any inheritance is supported in constexpr."
But I figured there must be a reason the original paper omitted virtual base support, so I went looking. The "support virtual calls in constexpr" paper was by Peter Dimov.
The name "Peter Dimov" reminded me that Peter was also the author of a paper proposing constexpr support for virtual destructors:
(My understanding is that P1077 is defunct: its ideas about "trivial" virtual destructors were superseded (unfortunately IMHO) by P0784's ideas about "non-trivial, yet still constexpr" destructors.)

Thinking about destructors reminded me that paper C++ is wishy-washy on exactly when (and even exactly how many times, IIRC) the destructor of a virtual base subobject will be called. A grandchild class following the Dreaded Diamond pattern might destroy its grandparent virtual base subobject during the destructor of the first parent, or during the destructor of the second parent, or after both, or even (IIRC) in the destructors of both parents. It seems like a terrible idea to carry over this wishy-washy behavior into compile-time evaluation.

So my hunch is that the problem has something to do with virtual base subobject destruction, and that's where I would advise you to look in the Standard and flesh out any possible problems and think about appropriate solutions.  You might also want to contact paper authors Peter Dimov and Daveed Vandevoorde and ask what's the problem that caused Daveed to forbid virtual bases in P0784. (I'd love to know the answer if you do find out!)

HTH,
–Arthur


On Fri, May 31, 2019 at 7:24 PM Lyberta via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
I have a serialization library that is designed very similar to standard
streams. So I have a very base class and virtually inherit input and
output streams from it. Naturally, most of the functions are virtual.

When I heard that virtual functions are allowed in constexpr in c++20, I
was excited because I thought I would be able to make most of the code
constexpr. Especially span streams that don't use any dynamic allocation.

When GCC 9 was released a month ago with support for virtual constexpr,
the first thing I tried is to aggressively add constexpr to my library.
I was immediately stopped by compiler because virtual base classes are
not allowed.

There is a proposal for text streams that use std::span - p0448. I think
if we allow constexpr virtual bases, we can have constexpr span streams
in p0448.

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Brian Bi