On Fri, 23 Dec 2022 at 10:13, Sébastien Bini <sebastien.bini_at_[hidden]>
wrote:

> I don't see the benefits of making it ill-formed for immovable types,
>>> while I clearly see some benefits of allowing it. A function taking a
>>> lock_guard by value needs not do anything different than before, since
>>> lock_guard has no relocation constructor. If the ABI allows it, then `reloc
>>> guard;` will call the destructor, otherwise it's ill-formed.
>>>
>>
>> OK. I want to avoid making discarded-value expressions magic, but maybe
>> we can accomplish that by having the relocation occur (or potentially
>> occur) at temporary materialization, as you've suggested.
>>
>
> That seems like the best approach.
>
>
>> The other thing I want is for well-formedness of code (here `reloc
>> guard;`) to not be platform-dependent. So `reloc guard;` is always valid,
>> but may prevent linking a calling TU compiled by an old compiler or under
>> an old standard.
>>
>
> Yes, well-formedness is important. I don't know how to make `reloc guard`
> always valid without breaking the ABI even more...
>
> Things are already complex enough, and I don't believe that is required to
> have for the MVP. So I'd say that relocation+destroy must be legal,
> although relocation may be elided (so `reloc guard;` is ill-formed because
> immovable). This is suboptimal, but at least it doesn't close the door to
> future evolutions. And another proposal can be made later, especially when
> we have a first feedback on how well the ABI evolution was handled by
> library/compiler vendors.
>

OK, I'm reluctantly coming round. The issue that's changed my stance is
that tricks with symbols and thunks are all very good, but function
pointers and virtual functions blow a hole in any such scheme; we cannot
require a change in ABI for function pointers and virtual functions taking
existing types unchanged across language (or compiler) versions.

So at minimum `reloc guard` will have to be ill-formed for `guard` a
by-value function parameter of an immovable type on Itanium. The question
is then whether this extends to callee-destroy platforms, and whether it
extends to local variables. I feel like saying that unmaterialized
temporaries relocated from function parameters behave differently is the
better option, such that `reloc guard` is always ill-formed for `guard` an
immovable by-value function parameter, and well-formed otherwise.