Hello Mauro and all,

I'll first say that I believe the discussion actually stems from a
StackOverflow question (I) asked a few days ago about this same subject:

https://stackoverflow.com/q/79974174/1593077

and the discussion it evoked.

Whether that's actually the case or just a coincidence - I believe,
Mauro, that the merited specification change is the opposite of what you
suggest. AFAICT, the compiler can very well generate a valid
move-assignment operator, which moves the virtual base class exactly once.

To illustrate this, consider the following 4-class diamond pattern, used
also in the SO question:

A , with custom move assignment
B : public virtual A , with defaulted move-assignment
C : public virtual A , with defaulted move-assignment
D : public virtual B, public virtual C , with defaulted move-assignment

Generating a move assignment for B (resp. C) is obvious: Apply the move
assignment of A, then move-assign each of the remaining data members of
B (resp. C).

Generating a move assignment for _D_ is a little more sophisticated, but
still rather straightforward: Given the fact that B and C are defaulted,
and the compiler know they comprise of move-assigning A and
move-assigning B\A (resp. C\A) - it can generate a move-assignment which
does the following:

move-assign A
move-assign B\A
move-assign C\A

and Bob's your uncle. The order of B before C is the order of listing of
parent classes in the class definition.

An SO user at the link raised a concern about consistency with
auto-generated copy-assignment; and others claimed that this complicates
the language too much, etc. I have not found those arguments very
convincing; but of course - I am not well-versed in the standard enough
to make a call, and maybe I've missed something. Have I?

Eyal




On 07/07/2026 11:11, mauro russo via Std-Discussion wrote:
> Following the message in
> https://lists.isocpp.org/std-discussion/2026/07/3433.php <https://
> lists.isocpp.org/std-discussion/2026/07/3433.php>
>
> I really believe that the behavior from [class.copy.assign]-p(12.3) :
> It is unspecified whether subobjects representing virtual base
> classes are assigned more than once by the implicitly-defined
> copy/move assignment operator
>
> has room for modification proposals, related to the move assign.op.
>
> Pls, anyone to clearly state it would not make sense to go
> for a step further in https://isocpp.org/std/submit-a-proposal <https://
> isocpp.org/std/submit-a-proposal>
>
> I might propose to go for define as deleted the move assign.op.
> as I don't see ways to work around it but not using at all.
> Providing an unspecified definition that most likely "clears"
> the objects state (moving twice or more), is totally unfair to me.
> Other cases of unspecified have a workaround, as for example
> the undetermined sequence in arguments evaluation for a
> function call -> just don't rely on any in the rest of the code.
> But here, I see nothing beyond just not using it.
> If not an undefined behaviour, why not being consistent and
> include in the rules to define as deleted ?
> Other options are possible (to me) but not keep it 'unspecified'.
>
> Kind regards.
> Mauro.
>