On Mon, 19 Dec 2022 at 17:52, Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello,
>
> On 19/12/2022 13:51, Sébastien Bini via Std-Proposals wrote:
> > The idea is then to guarantee that we have the callee-destroy ABI for
> > the purposes of relocation. We don't want to impact all functions, and
> > we want the library vendors to have full control over which functions
> > will keep their former ABI/call convention, as ABI stability is
> > important for some. This is what motivated the following rule: if a
> > function takes a value parameter whose type declares a relocation
> > constructor (understand, the class designer allowed relocation) then the
> > function is forced to have the callee-destroy ABI. Exceptions to this
> > rule are for trivial types (their destructor is a no-op so we don't care
> > how many times it's called), or for types defined with the opt-out class
> > attribute.
>
> Do you have a link at a latest version of this proposal? I feel I'm
> asking trivial questions:
>
> If I have an object of type T that doesn't yet have a relocation
> constructor, and I reloc such an object as the parameter to `f(T)`, what
> happens?
>
> * Does it turn the reloc into move ctor+dtor?
>

Yes, except that the dtor is invoked before calling `f` (I think it happens
immediately and not at the end of the enclosing expression?), and except
that the move ctor+dtor may be elided if the called function `f` is inlined.

* Does it also force the function ABI to be callee-destroy?
>

No.

* Sometime later, someone adds a relocation constructor to T. If my
> platform uses caller-destroyed by default, does `f`'s ABI
> "automatically" gets broken because it turns into callee-destroyed,
> unless someone tags T otherwise?
>

Yes.

This last point seems very unreasonable to me -- it sounds like the tag
> should be the opt-in to the ABI break (a bit like [[trivial_abi]] is),
> not opt-out.
>

The same goes for adding any of the Rule of Five special member functions.
Basically, Don't Do That if you want to preserve ABI.

(Clearly the point is that no one seems to want an ABI break, unless
> reloc can showcase that it will bring such immense benefits to justify
> it...)
>

It does. Performance is one; type safety is another (allowing truly
never-empty types); bug safety yet another (fully preventing use-after-move
bugs). There are other smaller benefits.

> And the reason for my email is that I'm worried that this simple class
> > attribute may not be enough, as for instance it is terrible for
> > composability.
>
> I'm not really sure without reading something concrete, but this seems
> to be falling the same bucket of synthesizing copies / moves /
> relocations (P1144) (/ [[trivial_abi]]), i.e. things compose
> "automatically" by default or you've got type traits to allow you to
> choose a composition strategy.
>

Yes, I agree on that part, if you mean that they should compose
automatically for defaulted special member functions (including for
aggregates).

My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>