[Development] HEADS-UP: Branching from '6.6' to '6.6.1' done
Hi! We have branched '6.6.1' from '6.6'. So from now on all changes targeted to Qt 6.6.1 release must have 'Pick-to: 6.6.1' and '6.6' is for Qt 6.6.2 release. As usual staging in '6.6.1' is restricted to release team only and we will monitor incoming changes and stage the clear ones in automatically. Please do not add any nice-to-haves in '6.6.1' anymore; those can wait Qt 6.6.2. The target is to release Qt 6.6.1 23rd of November 2023. br, Jani Heikkinen Release Manager -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
Il 14/11/23 09:12, Marc Mutz via Development ha scritto: Given that this is an API that is going to stay with us for at least a decade, I'd rather get it right than getting it soon. We're discussing various tangential aspects for half a year now. At some point, all the cards are on the table and all that talking needs to come to some conclusion. That point is now. Could this long thread be summarized somehow? I'm really unsure on the conclusions. I'd also welcome a discussion for QtCS, if it wasn't so close to the FF. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 14 November 2023 08:25:34 PST Ivan Solovev via Development wrote: > > The ABI functions can return one of these other types: > > bool (for equality comparisons) > > int (for non-partial ordering) > > QPartialOrdering (for partial ordering) > > IIUC, returning QPartialOrdering is exactly what we want to avoid, due to > the std::partial_ordering -> QPartialOrdering (and reverse) conversions. That boat sailed in 6.1 because QPartialOrdering is already used in QMetaType and QVariant API/ABI. Ideally for new out-of-line APIs, we could return a type that is ABI- compatible with std::partial_order. But how many of those are we going to get? > As we figured out earlier in this discussion, by making Qt::partial_ordering > binary compatible with std::partial_ordering, we will allow the compiler to > optimize the code and avoid the conversions (specially if we use > std::bit_cast). Yes, but the impact only applies to when it needs to translate from out-of- line to out-of-line. If either side is inline, it'll do the right thing on its own. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
> The ABI functions can return one of these other types: > bool (for equality comparisons) > int (for non-partial ordering) > QPartialOrdering (for partial ordering) IIUC, returning QPartialOrdering is exactly what we want to avoid, due to the std::partial_ordering -> QPartialOrdering (and reverse) conversions. As we figured out earlier in this discussion, by making Qt::partial_ordering binary compatible with std::partial_ordering, we will allow the compiler to optimize the code and avoid the conversions (specially if we use std::bit_cast). Thanks, Ivan From: Development on behalf of Thiago Macieira Sent: Tuesday, November 14, 2023 5:07 PM To: development@qt-project.org Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt) On Tuesday, 14 November 2023 04:17:18 PST Marc Mutz via Development wrote: > It's dangerously close to q20, yes, but q20 types switch at compile-time > between std and fall-back types, which means they cannot be used in the > ABI (yes, I used qxp::function_ref in QTestLib, but that doesn't have a > `using std::...`, yet, so we're still ok, and QTestLib doesn't have BC > constraints). Actually, how about we do exactly that: we DO NOT use them in the ABI and thus we DO use std:: types when compiling in C++20 mode. We can only use them in inline-only functions. The ABI functions can return one of these other types: bool (for equality comparisons) int (for non-partial ordering) QPartialOrdering (for partial ordering) -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 14 November 2023 04:17:18 PST Marc Mutz via Development wrote: > It's dangerously close to q20, yes, but q20 types switch at compile-time > between std and fall-back types, which means they cannot be used in the > ABI (yes, I used qxp::function_ref in QTestLib, but that doesn't have a > `using std::...`, yet, so we're still ok, and QTestLib doesn't have BC > constraints). Actually, how about we do exactly that: we DO NOT use them in the ABI and thus we DO use std:: types when compiling in C++20 mode. We can only use them in inline-only functions. The ABI functions can return one of these other types: bool (for equality comparisons) int (for non-partial ordering) QPartialOrdering (for partial ordering) -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 14 November 2023 04:17:18 PST Marc Mutz via Development wrote: > It's dangerously close to q20, yes, but q20 types switch at compile-time > between std and fall-back types, which means they cannot be used in the > ABI (yes, I used qxp::function_ref in QTestLib, but that doesn't have a > `using std::...`, yet, so we're still ok, and QTestLib doesn't have BC > constraints). > > The Qt::*ordering types, OTOH, are specifically _for_ use in the ABI. This does mean those types won't be documented, right? We forward to the C++ Standard Library documentation. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 14.11.23 11:54, Edward Welbourne wrote: > Volker Hilsheimer (14 November 2023 10:00) wrote: >> Adding Qt::snake_case interims that are BC with std, with conversion >> from/to QPartialOrdering, is the right thing to do. > > Perhaps namespace q20 would be a better place for them, given both the > naming (snake-case, to match stl) and the plan ? It's dangerously close to q20, yes, but q20 types switch at compile-time between std and fall-back types, which means they cannot be used in the ABI (yes, I used qxp::function_ref in QTestLib, but that doesn't have a `using std::...`, yet, so we're still ok, and QTestLib doesn't have BC constraints). The Qt::*ordering types, OTOH, are specifically _for_ use in the ABI. Thanks, Marc -- Marc Mutz 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
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 14 Nov 2023, at 10:00, Volker Hilsheimer via Development
wrote:
On 14 Nov 2023, at 09:40, Marc Mutz via Development
wrote:
On 14.11.23 09:31, Marc Mutz via Development wrote:
[...]
And then naming them Qt::partial_ordering is just consequent, because
users can reach ultimate SC by doing something like
#ifdef __cpp_lib_three_way_comparison
using std::partial_ordering;
#else
using Qt::partial_ordering;
#endif
~~~ use unqualified partial_ordering ~~~
This will also mean that in Qt 7 we can maintain 100% SC with Qt 6 by
simply saying
namespace Qt {
using partial_ordering = std::partial_ordering;
using weak_ordering = std::weak_ordering;
using strong_ordering = std::strong_ordering;
}
Done.
I agree with Marc here.
It’s tempting to add some Qt::Ordering::Partial, but it only makes things
harder in the not-so-long run. From C++ 23 on, we can expect
std::partial/weak/strong_ordering to become as ubiquitous as “true” and
“false”. We should not invent our own.
Adding Qt::snake_case interims that are BC with std, with conversion from/to
QPartialOrdering, is the right thing to do.
On 14 Nov 2023, at 11:54, Edward Welbourne wrote:
Adding Qt::snake_case interims that are BC with std, with conversion
from/to QPartialOrdering, is the right thing to do.
Perhaps namespace q20 would be a better place for them, given both the
naming (snake-case, to match stl) and the plan ?
and
On 14 Nov 2023, at 12:01, Tor Arne Vestbø wrote:
The naming makes sense, given their purpose. But can we put them in a dedicated
Qt::std_compat namespace? Or is that too late? That would make it clear these
are not Qt proper types (living in the Qt namespace), but dedicated compat
types/BC/SC vehicles
We have so far not used any q20/23/xp APIs in public Qt API, and those
namespaces are not documented. The intention was for them to be used
internally, and the qNN headers contain the “not part of the Qt API” warning.
This doesn’t have to be set in stone, of course. Perhaps this is the exception
that confirms the rule.
OTOH, if the only reason for not using Qt::snake_case is because of the
snake_case, then it seems overly complicated to make that exception, or to
introduce a new namespace. It’s going to be part of practically every
value-type we have in Qt, which makes it a very very ubiquitous “exception”. We
have QList::push_back and QList::const_iterator for compatibility with the
standard. I don’t quite see why it would not be ok for Qt::*_ordering to exist
as a proper Qt names. The only difference here is that we don’t want to
introduce a Qt::CameCase equivalent, for the reasons given by Marc.
That they are short-lived as “independently defined entities” is an
implementation detail. Qt::*_ordering will work throughout the Qt 6 life-time,
also once they are just aliases to std::*_ordering; there won’t even be a real
reason to remove them for Qt 7.
On 14 Nov 2023, at 11:54, Edward Welbourne also wrote:
Speaking of q20, I notice its files live in corelib/global/; it occurs
to me that perhaps corelib/compat/ might be more natural (mainly because
it's the first place I looked for them). They are, after all, a piece
of compatibility machinery, albeit between Qt and C++ rather than
between Qt versions (as such - of course, the Qt versions' change of C++
standard does make them indirectly also between Qt versions).
Eddy.
module/compat is about backward compatibility with older Qt versions, and in
practice only includes the respective removed_api.cpp implementation file.
We include those qNN headers in public headers, and including something from
“compat” in public headers seems wrong.
Volker
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
The naming makes sense, given their purpose. But can we put them in a dedicated
Qt::std_compat namespace? Or is that too late? That would make it clear these
are not Qt proper types (living in the Qt namespace), but dedicated compat
types/BC/SC vehicles .
Tor Arne
On 14 Nov 2023, at 10:00, Volker Hilsheimer via Development
wrote:
On 14 Nov 2023, at 09:40, Marc Mutz via Development
wrote:
On 14.11.23 09:31, Marc Mutz via Development wrote:
[...]
And then naming them Qt::partial_ordering is just consequent, because
users can reach ultimate SC by doing something like
#ifdef __cpp_lib_three_way_comparison
using std::partial_ordering;
#else
using Qt::partial_ordering;
#endif
~~~ use unqualified partial_ordering ~~~
This will also mean that in Qt 7 we can maintain 100% SC with Qt 6 by
simply saying
namespace Qt {
using partial_ordering = std::partial_ordering;
using weak_ordering = std::weak_ordering;
using strong_ordering = std::strong_ordering;
}
Done.
I agree with Marc here.
It’s tempting to add some Qt::Ordering::Partial, but it only makes things
harder in the not-so-long run. From C++ 23 on, we can expect
std::partial/weak/strong_ordering to become as ubiquitous as “true” and
“false”. We should not invent our own.
Adding Qt::snake_case interims that are BC with std, with conversion from/to
QPartialOrdering, is the right thing to do.
Volker
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
Volker Hilsheimer (14 November 2023 10:00) wrote: > Adding Qt::snake_case interims that are BC with std, with conversion > from/to QPartialOrdering, is the right thing to do. Perhaps namespace q20 would be a better place for them, given both the naming (snake-case, to match stl) and the plan ? Speaking of q20, I notice its files live in corelib/global/; it occurs to me that perhaps corelib/compat/ might be more natural (mainly because it's the first place I looked for them). They are, after all, a piece of compatibility machinery, albeit between Qt and C++ rather than between Qt versions (as such - of course, the Qt versions' change of C++ standard does make them indirectly also between Qt versions). Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
> On 14 Nov 2023, at 09:40, Marc Mutz via Development
> wrote:
>
> On 14.11.23 09:31, Marc Mutz via Development wrote:
> [...]
>> And then naming them Qt::partial_ordering is just consequent, because
>> users can reach ultimate SC by doing something like
>>
>> #ifdef __cpp_lib_three_way_comparison
>> using std::partial_ordering;
>>
>> #else
>> using Qt::partial_ordering;
>> #endif
>>
>> ~~~ use unqualified partial_ordering ~~~
>
> This will also mean that in Qt 7 we can maintain 100% SC with Qt 6 by
> simply saying
>
>namespace Qt {
>using partial_ordering = std::partial_ordering;
>using weak_ordering = std::weak_ordering;
>using strong_ordering = std::strong_ordering;
>}
>
> Done.
I agree with Marc here.
It’s tempting to add some Qt::Ordering::Partial, but it only makes things
harder in the not-so-long run. From C++ 23 on, we can expect
std::partial/weak/strong_ordering to become as ubiquitous as “true” and
“false”. We should not invent our own.
Adding Qt::snake_case interims that are BC with std, with conversion from/to
QPartialOrdering, is the right thing to do.
Volker
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 14.11.23 09:31, Marc Mutz via Development wrote:
[...]
> And then naming them Qt::partial_ordering is just consequent, because
> users can reach ultimate SC by doing something like
>
> #ifdef __cpp_lib_three_way_comparison
> using std::partial_ordering;
>
> #else
> using Qt::partial_ordering;
> #endif
>
> ~~~ use unqualified partial_ordering ~~~
This will also mean that in Qt 7 we can maintain 100% SC with Qt 6 by
simply saying
namespace Qt {
using partial_ordering = std::partial_ordering;
using weak_ordering = std::weak_ordering;
using strong_ordering = std::strong_ordering;
}
Done.
--
Marc Mutz
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
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 13.11.23 19:24, Thiago Macieira wrote: [...] > It could be done, but I just don't see the value. I do. > If we do it, please come up with proper Qt-style class names for it. No > snake_case. No. We don't _want_ these to be Qt-style classes. _You_ should not want them to be Qt-style classes. They're _not_ Qt classes, they're SC and BC vehicles to emulate the std classes as close as possible. We don't want to have to carry them around come Qt 7. You shouldn't want to have to carry them around come Qt 7. So it must be ::less, not ::Less, and is_neq and not qIsNotEqual. Any epsilon of divergence to the std classes will cause users to accidentally depend on the difference. Hyrum's Law. So we need to minimize that difference as much as humanly possible. And then naming them Qt::partial_ordering is just consequent, because users can reach ultimate SC by doing something like #ifdef __cpp_lib_three_way_comparison using std::partial_ordering; #else using Qt::partial_ordering; #endif ~~~ use unqualified partial_ordering ~~~ This is the best for our users. Any Qt-ification of these std copies will just increase the porting overhead for our users. In no universe would that be good for our users. We know where we need to go: no Qt::ordering classes, only std::ordering, and anything that distracts either our users or ourselves from that goal is counter-productive. Thanks, Marc -- Marc Mutz 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
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 13.11.23 19:25, Thiago Macieira wrote: > On Monday, 13 November 2023 09:38:43 PST Ivan Solovev via Development wrote: >> I really do not want to miss yet another FF. > > Given that this is an API that is going to stay with us for at least a decade, > I'd rather get it right than getting it soon. We're discussing various tangential aspects for half a year now. At some point, all the cards are on the table and all that talking needs to come to some conclusion. That point is now. Thanks, Marc -- Marc Mutz 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
