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

[Ivan Solovev]

> I think it's acceptable for us to change the return type of a function so long
> as it's getting a new mangling.

Well, it would be easily achievable for the template methods, but not for the
inline hidden friend helper methods.
As immediate solution that comes to my mind is to add a third argument to
these methods when compiled in C++20 mode. And we could probably use
yet another macro for that. But this will just overcomplicate the things, so
I'm not a big fan of this idea.

> 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.

So, you say that the compiler is smart enough to optimize away conversions like
`std::strong_ordering -> QStrongOrdering -> std::strong_ordering`
because the underlying integral values are the same?

I did some experiments in compiler explorer, and it seems that gcc and clang
generate similar assembly code with and without conversions.
MSVC is a bit special here, however.
See my experiments here:https://godbolt.org/z/G8Ks9v9Ks

In this case we could probably apply Marc's proposal #3 (making std::* and Qt::*
types binary compatible), and just stick to the Qt::* types in the API?

Thanks,
Ivan

________________________________
From: Development <development-bounces at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Wednesday, November 8, 2023 4:46 PM
To: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231108/e5d5d0b9/attachment-0001.htm>