On Wed, 29 Oct 2025 at 15:03, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> 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.
https://cplusplus.github.io/LWG/issue3828



> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>