>From: Development on behalf of Volker
>Hilsheimer
>Lets continue with this for Qt 6.7.
>Even if we agree on the naming and can exclude binary compatibility issues,
>rolling this out to all (or at least a substantial amount of) existing value
>types a
Hi,
https://codereview.qt-project.org/c/qt/qtbase/+/308602 has been "ready"
for a while, but got stalled because I'm unsure I want to implement the
proposed changes.
I'd like QVariantMultiMap and QVariantMultiHash to be first-class, just
like QVariantMap and QVariantHash. That includes a const
On 5 Jun 2023, at 09:11, Jukka Jokiniva via Development
wrote:
Hi,
There are quite many changes trying make it to the qt/qt5 dev branch:
https://codereview.qt-project.org/q/project:qt/qt5+branch:dev+is:open
If everyone starts to stage these individually, I am afraid that nothing will
get merg
> On 4 Jun 2023, at 23:26, Thiago Macieira wrote:
>
> On Sunday, 4 June 2023 11:51:54 PDT Marc Mutz via Development wrote:
>>> The other problem is I want to take a second, thorough look at your
>>> #ifdefs
>>> for C++20. I have a feeling some of the changing return types are a recipe
>>> for bin
> On 3 Jun 2023, at 16:54, Thiago Macieira wrote:
>
> On Saturday, 3 June 2023 02:54:49 PDT Marc Mutz via Development wrote:
>> The container-assign epic is partially merged. What's left is
>> QString::assign(), and there only the assign(it, it) part. If we release
>> as-is (with step 1, cf. be
Hi,
There are quite many changes trying make it to the qt/qt5 dev branch:
https://codereview.qt-project.org/q/project:qt/qt5+branch:dev+is:open
If everyone starts to stage these individually, I am afraid that nothing will
get merged because of the flakiness and we just overload the CI.
Would it
