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_at_[hidden]> 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.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1064r0.html
> The name "Peter Dimov" reminded me that Peter was also the author of a
> paper proposing constexpr support for virtual destructors:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1077r0.html
> (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.)
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0784r3.html
>
> 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_at_[hidden]> 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_at_[hidden]
>> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*