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.)

HTH,
Arthur