On Thursday, 30 October 2025 08:15:33 Pacific Daylight Time Giuseppe D'Angelo
via Std-Proposals wrote:
> No. P2786 / trivial relocation as per the current working draft doesn't
> grant any special features to realloc(). std::trivially_relocate is the
> only entry point for trivial relocation.

Then we won't use this in Qt.

> From my understanding, P3858 (likely C++29 material at this point)
> wants to correct this by introducing a lower-level primitive than
> std::trivially_relocate.

Great, so we can rely on it in 2033-2035.

Though if the current trivial relocatability is yanked, we won't get a
replacement fix until the same time frame, so it's not a big deal for us to
continue with our Q_DECLARE_TYPEINFO solution until then.

> The idea is that you will be able to move object representations in
> memory using *any* facility you like (including realloc()), but then you
> need to call std::restart_lifetime<T>() to tell the abstract machine¹
> that there are objects of type T at the destination whose lifetime needs
> to be started.

I'm fine with that, so long as that is an O(1) operation for an array of any
size for *properly* trivially relocatable types. So long as we have this:

> I'm also 99% sure that P3858 does not solve the problem of detecting
> bitwise trivial relocability (detection that we need for things like
> QVariant), but that's a separate can of worms...

Because we either need to type-erase the operation for QVariant, or we need to
reject allowing this type to live in QVariant's "small object optimisation"
buffer, if the operation needs to do anything that memcpy() didn't.

> ¹ But also the physical machine: if T is polymorphic / contains
> polymorphic subobjects, it will deal with the vtable re-signing on arm64e.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.