On Sat, Jan 24, 2026 at 9:22 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:

> On Saturday, January 24, 2026, Thiago Macieira wrote:
>
>>
>> And it's only worse when we consider you want it to be
>> non-cross-platform. I think that's a DOA request.
>
>
> The term you seek is "implementation-specific behaviour".
> So the Standard would say something like:
>
> === is_trivially_copy_constructible ===
>
> - For polymorphic objects, trait will always be false if the following
> expression is false: 'is_final_v<T> || guaranteed_complete_object'.
> - For polymorphic objects, trait will be implementation-defined if the
> following expression is true: 'is_final_v<T> || guaranteed_complete_object'.
>
> But that's only if we don't also introduce "std::copy_lifetime". If we
> introduce "std::copy_lifetime" then [...]
>

You seem to be reinventing the idea of a "copy constructor." That's a
function that takes an object at one place in memory and gets (a copy of)
it into another place, doing whatever fixup is necessary to make it work in
the new place (as well as in the old place). Or maybe you're reinventing
"move constructor" (which gets the value of the object into another place,
albeit potentially leaving the source object with a different value) or
maybe P3516 / P1144 "std::relocate_at" (which gets the value of the object
into another place, while destroying the source object entirely)... It's
impossible to tell exactly what operation you want to do, except that you
have the idea that it's *sometimes* *somewhat* similar to memcpy.
Anyway, we already have all three of these operations in C++. The only
question to ask of a trait is, "Can I *100% safely* replace this *operation*
with memcpy?" — and we have traits for all these things already. Your vague
thinking about operations that are *sometimes* *somewhat* similar to
memcpy isn't relevant to production code.

–Arthur