hello Marcin,

thanks for the interest.

No, I never stated I am interested to make it 'defined' with the guarantee
of a single action on each virtual base.
Indeed, my proposal would likely be to go for 'defined as deleted'.

The main concern currently is that the standard indicates it
as 'unspecified', with a big danger in using it.
Since I see no way to work around it but not using it
at all, then why keeping it unspecified for move assign.op. ?


Il giorno mar 7 lug 2026 alle ore 11:21 Marcin Jaczewski <
marcinjaczewski86_at_[hidden]> ha scritto:

> Question is if it's possible to make it defined? and at what cost?
>
> As each middle base class move assignment function do not know if the
> current object is the only "owner"
> of this virtual base object or not. In theory the constructor of the
> current object knowed this but it's still available after that?
>
> Another thing is that is this possible without breaking ABI?
>
> wt., 7 lip 2026 o 10:11 mauro russo via Std-Discussion
> <std-discussion_at_[hidden]> napisał(a):
> >
> > Following the message in
> > 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
> >
> > 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.
> > --
> > Std-Discussion mailing list
> > Std-Discussion_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>