Date: Mon, 19 Dec 2022 17:52:36 +0100
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?
* Does it also force the function ABI to be callee-destroy?
* 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?
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.
(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...)
> 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.
My 2 c,
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?
* Does it also force the function ABI to be callee-destroy?
* 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?
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.
(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...)
> 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.
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
Received on 2022-12-19 16:52:39