wt., 7 lip 2026 o 14:42 mauro russo <ing.russomauro_at_[hidden]> napisał(a):
>
> 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'.
>

Ok, this makes sense.
This will apply to all cases? Like:

```
struct Foo
{
};
struct Bar : virtual Foo
{
};

int main()
{
    Bar b;
    b = Bar{};
}
```

This code will be lagal after your change?
I think we could still allow it and only ban hard cases.


Overall only way for user to have move operation on type like this is:
```
VirtualBase temp = std::move(*(VirtualBase*)&other);
*(BaseA*)this = std::move(*(BaseA*)&other); //move empty `VirtualBase`
*(BaseB*)this = std::move(*(BaseB*)&other); //move empty `VirtualBase`
*(VirtualBase*)this = std::move(temp);
```
This add lot of new moves there but at least final values will be preserved.
Another problem is a lot of typing and boilerplate.

> 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