On Thursday, 30 October 2025 12:25:07 Pacific Daylight Time Oliver Hunt wrote:
> > On Oct 30, 2025, at 10:44 AM, Thiago Macieira via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> >
> > On Thursday, 30 October 2025 10:17:47 Pacific Daylight Time Sebastian
> > Wittmeier>
> > via Std-Proposals wrote:
> >> What is the disadvantage of using std::trivially_relocate()?
> >
> > Unless it's guaranteed to be no-op for everyone, it requires extracting
> > for
> > type-erasure, something we don't do now. And if it requires extracting for
> > *some* types, I need to know which types it is required for, so I don't
> > have to extract it for all types. Extracting unnecessarily creates more
> > relocations (used here in the old sense) in the binary, which slows down
> > load time.
> I still don’t understand this - how do you deal with non-copyable types
> today?

Those don't get the benefit of the "small object optimisation". The
"canUseInternalSpace" is a combination of the type being small enough (3
pointers or less) and being relocatable. The naming there is just new enough
to have caught some of the discussion on relocatability, but not new enough to
call it "trivially relocatable" or even "bitwise trivially relocatable".

https://github.com/qt/qtbase/blob/dev/src/corelib/kernel/qvariant.h#L102-L109

I don't know where the std::is_polymorphic check ended up - it's nowhere in
the lib. Peppe will remember. We may have decided to wait for the Standard to
make up its mind.

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