On Tue, Aug 23, 2022 at 7:25 PM Edward Catmur <ecatmur_at_[hidden]>
wrote:

> On Tue, 23 Aug 2022 at 12:40, Sébastien Bini <sebastien.bini_at_[hidden]>
> wrote:
>
>> If I understand correctly, you suggest that aliasing be mandated only for
>> types that have a relocation constructor and have not opted-out of the ABI
>> break? I like this idea, it further avoids another keyword in the operator
>> declaration.
>>
>> But what about trivial types, which follow the rule of zero?
>>
>> struct S { int _d; S& operator=(S rhs) { _d = rhs._d; return *this; } };
>>
>> They will get a relocation constructor for free, even if none of their
>> subobjects explicitly provides a relocation constructor. Had they declared
>> a prvalue-assignment operator, then it would change its ABI silently. It's
>> okay for them to silently go from caller-destroy to callee-destroy as their
>> destructor is a no-op, but aliasing will also force the parameter to share
>> the same address as the caller's site source object, which is a silent ABI
>> break.
>>
>
> It's not always an ABI break. On all 64-bit ABIs that I'm aware of (see
> https://www.agner.org/optimize/calling_conventions.pdf), the caller is
> responsible for allocating and cleaning up stack space used by oversized /
> non-trivial objects, so the callee doesn't need to know whether aliasing is
> occurring.
>
> On the other hand, it is an ABI break on most 32-bit ABIs. But your
> example struct doesn't even follow the rule of zero (once relocating
> assignment becomes a special member function), so maybe it would be OK if
> aliasing doesn't occur in that specific case. In fact, it's quite possible
> that the presence of a user-declared relocating assignment operator would
> suppress the relocating constructor, so it definitely wouldn't be a
> candidate for aliasing?
>

Indeed, that would not comply with the rule of zero. And similarly to the
move semantics (if a move-assign operator is declared then the move
constructor is not implicitly declared), I suppose the explicit declaration
of the prvalue-assign should also inhibit the implicit declaration of the
relocation constructor.

Well, unless I am missing something, it looks like we clarified all the
blocking points so far? Thanks for your help in moving this forward!

What are the next steps? I guess another revision of the proposal needs to
be written?