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