[Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

[Thiago Macieira]

On Wednesday, 8 November 2023 00:38:32 PST Marc Mutz via Development wrote:
> Let's not mix up topics here...
> 
> 1/ We're not responsible for the ABI of third-party libraries. As long as
> we document that the return type of a non-exported inline functions
> changes, then it's SEP if someone else writes code that ties their ABI
> to the result type of such functions.

Fair, but we are responsible if we make it difficult for them to do this, or 
make it trivial for them to have the problem without knowing that they have 
it. That was the issue with std::string in libstdc++: it kept libstdc++ BC, 
but broke everyone downstream of it.

> That leaves 2/ the mythical "merge of inline functions from different
> libraries" and 3/ "mixing of C++ versions within the same executable"
> situations.
> 
> I agree that the latter is a problem; I stated as much in my previous
> email, and gave (1) and (3) as solutions.
> 
> But I still don't see how the former is a problem, or, if it is, why (3)
> (BC between {std,Qt}::_ordering) doesn't fix it, too.

I think it's acceptable for us to change the return type of a function so long 
as it's getting a new mangling. That means it can apply to any regular 
function, but not operators. Then again, all of the latter return bool except 
for operator<=> so there's no problem there either.

But why take the risk? The performance impact is minimal, because it only 
applies to partial ordering, while the vast majority of types are fully 
ordered. The impact of QAnyStringView in any API is greater.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5163 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231108/0742af5e/attachment.bin>