On Wednesday, October 29, 2025, Giuseppe D'Angelo wrote:
You are of course free to say that this doesn't match your mental model of triviality; nor the (non-standard) pre-existing practice in many libraries; nor even the new practice (e.g. Proxy v3).
I'd even agree with such a position; that's why I wrote P3780.
This reminds of the back-and-forth I had about __uint128_t and why it's bigger than uintmax_t.
(Point No. 1) __uint128_t is a type
(Point No. 2) __uint128_t stores an integer
(Point No. 3) __uint128_t is not an integer type
That paradox was already resolved for C++23.
I'm not keen on bending of the English language . . . reminds me of how the Northern-most county of Ireland is said to be in the South.
If the relocation of an object involves the invocation of a hash algorithm or an encryption algorithm, then 'trivial' is a very poor choice of word. Maybe something more suitable like "has_specialized_relocation_algorithm". But even with that, I would argue that the invocation of a hashing/encryption algorithm is tantamount to "having a specialised relocation algorithm".
So maybe a better term would be "custom_written" or "custom_composed", or better yet: "custom_implemented".
The standard already has a term for that:
"A function is user-provided if it is user-declared and not explicitly defaulted or deleted on its first declaration."
So we would say that std::string, in the short string optimization mode, has a custom-implemented relocation algorithm:
std::has_custom_implemented_relocator
And we could then reserve the meaning of "is_trivially_reloctable" to mean that you can do a memcpy without editing any bits.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals