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

[Marc Mutz]

On 08.11.23 16:46, Thiago Macieira wrote:
> 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.

std::string is a type, but we're talking about function return types. 
Oranges and apples. Naturally the impact of the former is orders of 
magnitude larger than that of the latter.

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

Why do you say it only applies to partial ordering? Do we already match 
the values, other than that of std::partial_ordering::unordered?

> The impact of QAnyStringView in any API is greater.

Unrelated.


I do note that you didn't attempt to poke holes into my documentation of 
my understanding of the "merge of inline functions from different 
libraries" issue.

To TL;DR: it: I believe there is no way that an (application or) library 
can call another (dynamic) library's implementation of a non-exported inline 
function. It will always contain (and call) its own copy of the 
non-exported inline function.

Independent of the resolution of the C++20 comparison return types, I 
think it's vital to come to a common understanding of whether there is 
an actual issue with non-exported inline functions in ABIs (and then 
document it in the KDE BC wiki).

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B