The attribute means that the user has to micro-manage individual
function parameters. One more thing to worry about.


If gcc/clang users[1] don't like the Linux ABI's choice of destroying
the parameter at the end of the enclosing full-expression, then they
should contribute patches to the Itanium ABI and gcc/clang to allow
opting-in to a new ABI where parameters are destroyed at the end of a
function. I don't think the Standard should work around deficiencies in
some implementations that can be fixed completely within the scope of
those implementations.



[1] I'm one of them.

On 07/08/2022 20.38, Jonathan Tanner wrote:
> This doesn’t really need to be a question of explicitly changing the
> ABI, the standard says:
>
> It is implementation-defined whether the lifetime of a parameter ends
> when the function in which it is defined returns or at the end of the
> enclosing full-expression.
>
> This proposal would just define the lifetimes of parameters with a
> particular tag/attribute. I’d probably use an attribute not a keyword,
> adding an attribute can be an ABI breaking change, see no_unique_address.
>
> Jonathan
>
>> On 7 Aug 2022, at 15:21, Avi Kivity via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>
>> 
>>
>>
>> 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_at_[hidden]> wrote:
>>>
>>> pt., 29 lip 2022 o 20:20 Arthur O'Dwyer
>>> <arthur.j.odwyer_at_[hidden]> napisał(a):
>>> >
>>> > On Thu, Jul 28, 2022 at 5:26 PM Marcin Jaczewski via
>>> Std-Proposals <std-proposals_at_[hidden]> 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.
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals