On 29/07/2022 21.42, Arthur O'Dwyer via Std-Proposals wrote:
On Fri, Jul 29, 2022 at 2:26 PM Marcin Jaczewski <marcinjaczewski86@gmail.com> wrote:
pt., 29 lip 2022 o 20:20 Arthur O'Dwyer <arthur.j.odwyer@gmail.com> napisaƂ(a):
>
> On Thu, Jul 28, 2022 at 5:26 PM Marcin Jaczewski via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
>>
>> Currently there are multiple problems linked to lifetime of function parameters.
>> Simply current default behavior does not fit all corner cases.
>>
>> Example is `std::unique` that generates subpar code because the call
>> site is a firewall that prevents the compiler to see at once destructor and move operation.
>
>
> Can you elaborate on this? I admit I've never thought about `std::unique` in this context before; but now that I have spent an hour or so thinking about it, I still don't see how its current behavior can be improved. One might rewrite `std::unique` to use swap instead of move-assignment, but one can't really rewrite it to use relocation because `std::unique` is never responsible for destroying anything. N objects go in, N objects come out (and in the same memory locations, too).
> https://p1144.godbolt.org/z/8v1Yj1eGK
>
> What would you do differently here?
>
Sorry, I mistyped, I mean type `std::unique_ptr` not algorythm `std::unique`.

Aha. In that case, is your proposal any different from the existing attribute [[trivial_abi]]?
https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/
https://libcxx.llvm.org//DesignDocs/UniquePtrTrivialAbi.html
https://godbolt.org/z/f59T4Tev1

([[trivial_abi]] is vendor-specific, not part of the ISO standard; but if your proposal really just boils down to "Hey, WG21 should just standardize [[trivial_abi]]," then you should say that.)


IMO, that's wrong. The standard leaves the ABI to the implementation. Standardizing [[trivial_abi]] means the standard acknowledges multiple ABIs, and requires the user to micro-manage the ABI of each type if they care about performance.


The implementations should just switch to a better ABI - callee-destroy, and pass-by-register if it can prove no self-references are involved (e.g. by type-based alias analysis, trivial for std::unique_ptr).


Yes, switching ABIs is a huge pain, but it has been managed in the past. gcc switched from reference-counted std::string to non-reference-counted std::string with SBO, and there were minor ABI updates when bugs were found in the implementation. The implementations are stuck in a deep hole, but [[trivial_abi]] makes that hole a little deeper.