On Thursday, 30 October 2025 11:14:14 Pacific Daylight Time Giuseppe D'Angelo
via Std-Proposals wrote:
> * One is indeed vector reallocation, where we want to keep using
> realloc() or similar. Assuming things stay as they are today, C++26
> won't give us anything to satisfy this use case so we'll be stuck in
> "UB that works in practice" land.
>
> The only thing we might decide to do is to amend the detection inside
> QVector, and to use realloc() not only on the types that we mark as
> trivially relocatable using Qt's markup, but also to those that are
> bitwise trivially relocatable as per the language.

There needs to be a trait for "bitwise trivially relocatable" for that.
Without one, nothing changes from our 2005 implementation.

> * Another is inserting/erasing in the middle of a vector. Here we could
> actually use std::trivially_relocate() instead of memmove(), as the
> result is the same.

Indeed, but that requires the vector have spare capacity.

BTW, this would imply ARM64e is only supported with C++26 or later, or a
compiler that provides the implementation intrinsic as an extension in earlier
versions. Since the arch is an opt-in anyway, I don't foresee a problem in
mandating the requirement.

> > 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.
>
>
> We'll certainly continue with Q_DECLARE_TYPEINFO for a very long time
> anyhow :)

I meant exclusively, not just for backwards compatibility. Ideally, if P1144
had been adopted, we'd be telling users to use the new attribute for all new
code they write and that they can skip the Q_DECLARE_TYPEINFO if they are sure
of C++26.

Whatever happens now, the minimum for foregoing Q_DECLARE_TYPEINFO in new code
is C++29.

> >> 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.
>
> If there's nothing to realize on the physical machine, what else could
> it be?

This requirement:

> > 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.
>
> That's precisely the use case for detecting bitwise trivial relocation.

That's the only operation I care. Anything that is type-specific can be non-
trivial relocation because it can only happen in generic code anyway.

If that generates slower code for ARM64e because we use realloc() less often
and don't store the type in QVariant's buffer, then so be it. Security often
comes at a price anyway.

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