[Development] HEADS-UP: Branching from '6.6' to '6.6.1' done

2023-11-14 Thread Jani Heikkinen via Development
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

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

2023-11-14 Thread Giuseppe D'Angelo via Development
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

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

2023-11-14 Thread Thiago Macieira
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

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

2023-11-14 Thread Ivan Solovev via Development
> 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

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

2023-11-14 Thread Thiago Macieira
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

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

2023-11-14 Thread Thiago Macieira
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

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

2023-11-14 Thread Marc Mutz via Development
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

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

2023-11-14 Thread Volker Hilsheimer via Development
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

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

2023-11-14 Thread Tor Arne Vestbø via Development
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,

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

2023-11-14 Thread Edward Welbourne via Development
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 ?

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

2023-11-14 Thread Volker Hilsheimer via Development
> 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

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

2023-11-14 Thread Marc Mutz via Development
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 >

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

2023-11-14 Thread Marc Mutz via Development
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.

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

2023-11-14 Thread Marc Mutz via Development
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