On Wed, 18 May 2022 at 06:33, Sébastien Bini <sebastien.bini_at_[hidden]>
wrote:

> I am thinking we could add a new class attribute [[reloc_parameter]]. Any
> function that has an object with this attribute in its parameters, captured
> by value, will force the function to use an ABI that allows it to relocate
> any of its input parameters.
>
> std::relocate_t could have that attribute: namespace std { struct
> [[reloc_parameter]] relocate_t {}; }
>
> And then any function that takes an 'std::relocate_t' by value as
> parameter will be allowed to relocate all its input parameters. The impact
> is minimal as, in the STL, std::relocate_t would always need to be passed
> around to distinguish between the overloads that capture objects by
> reference.
>
> That way STL classes can provide their own 'operator reloc()' member
> function, without changing the ABI. The ABI change is opt-in, only if the
> function has that std::relocate_t parameter. STL classes do not need to
> have the [[reloc_parameter]] attribute, only std::relocate_t needs it.
>

I recognize the issue, but I dislike the implication that we should have to
contort our code to get optimal performance, just because some people want
to be able to combine code compiled under different compilers or language
versions. ABI compatibility is simply not a concern for us, since we
recompile all C++ code at any change in compiler or compiler flags, via
source-only, statically linked, incremental builds.

Instead, and recognizing that maintaining ABI compatibility is an expert
task, can we make the ABI break opt-out? My idea would be an attribute that
standard library authors can place on classes that they want to add
relocate operator to but want to keep the old ABI for function argument
passing. Since the attribute would be a contract between standard library
and compiler, it wouldn't even need to be standardized, just enough
latitude given to the compiler that it can use move+destroy on function
parameters even when a relocate operator proper is also available. The
attribute would need to propagate from base+members to derived / containing
classes, but that should be feasible.