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.m...@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
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
