Date: Fri, 20 May 2022 07:23:32 -0700
On Friday, 20 May 2022 06:01:58 PDT Edward Catmur wrote:
> And if we don't get the ability to pass smart pointers in registers, and to
> pass around relocate-only types and use them without gymnastics, then
> there's really no point in this proposal at all.
I disagree. There's a lot of value in doing relocation for dynamic-storage
objects (i.e., inside of containers). THAT is what I'd like to see solved in
the first place, because it's something we already do in a lot of containers,
most aggressively in QVector. Standardising it would be very welcome.
Everything else is a bonus.
> We broke ABI for std::string ten years ago; have we really lost our courage
> since then?
No, we've learned that it WAS a break. libstdc++ tried to pass that change as
"it's not an ABI break because we're keeping both" but it caused all sorts of
compatibility problems that are excluisve of ABI breaks... only it was
downstream of libstdc++ by one library. It was an indirect ABI break and it
affected ALL libraries that used std::string aside from libstdc++ itself.
> Especially since now we have more tools - inline namespaces, modules,
> sanitizers - to make an ABI break less painful.
Yes, we can make what would otherwise be a silent breakage non-silent.
> And if we don't get the ability to pass smart pointers in registers, and to
> pass around relocate-only types and use them without gymnastics, then
> there's really no point in this proposal at all.
I disagree. There's a lot of value in doing relocation for dynamic-storage
objects (i.e., inside of containers). THAT is what I'd like to see solved in
the first place, because it's something we already do in a lot of containers,
most aggressively in QVector. Standardising it would be very welcome.
Everything else is a bonus.
> We broke ABI for std::string ten years ago; have we really lost our courage
> since then?
No, we've learned that it WAS a break. libstdc++ tried to pass that change as
"it's not an ABI break because we're keeping both" but it caused all sorts of
compatibility problems that are excluisve of ABI breaks... only it was
downstream of libstdc++ by one library. It was an indirect ABI break and it
affected ALL libraries that used std::string aside from libstdc++ itself.
> Especially since now we have more tools - inline namespaces, modules,
> sanitizers - to make an ABI break less painful.
Yes, we can make what would otherwise be a silent breakage non-silent.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Received on 2022-05-20 14:23:34