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

[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 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)

[Ivan Solovev via Development]

Marc wrote:
> I think I speak for Ivan, too, if I say that we'd rather
> today than tomorrow see this stuff merged. The next FF is already
> approaching again.

Right! This now seems to be the only thing blocking the whole
chain, and I think Marc's proposal solves all the issues.
I really do not want to miss yet another FF.

Best regards,
Ivan


From: Development  on behalf of Marc Mutz 
via Development 
Sent: Monday, November 13, 2023 6:15 PM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On 13.11.23 17:15, Thiago Macieira wrote:
> On Monday, 13 November 2023 01:34:08 PST Ivan Solovev via Development wrote:
>> Thiago wrote:
>>> The problem is that QPartialOrdering::Unordered has been in our ABI since
>>> 6.1 and we can't change that any more.
>>
>> Well, Marc already suggested a solution for this problem.
>> Let's just introduce Qt::{strong,weak,partial}_ordering and deprecate
>> QPartialOrdering in favor of the new types.
>>
>> We need to provide conversion between QPartialOrdering and
>> Qt::partial_ordering, but the new types can be fully BC with std.
>
> I don't think this minor thing is worth the hassle. It uglifies our API for
> little gain.

What, specifically, is ugly? That we have two Qt partial_ordering types?

Anyway, that's subjective. Objectively, it breaks the impasse between
full efficiency in future-looking C++20 builds and Qt BC guarantees.

Given that Qt 7.0 is many years away, I don't think it's too much to ask
to go the extra mile and remove the overhead. We seem to agree how to do
it technically, and it won't be on you to implement all this, but on
Ivan and me. I think I speak for Ivan, too, if I say that we'd rather
today than tomorrow see this stuff merged. The next FF is already
approaching again.

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

[Ivan Solovev via Development]

Thiago wrote:
> The problem is that QPartialOrdering::Unordered has been in our ABI since 6.1
> and we can't change that any more.

Well, Marc already suggested a solution for this problem.
Let's just introduce Qt::{strong,weak,partial}_ordering and deprecate 
QPartialOrdering
in favor of the new types.

We need to provide conversion between QPartialOrdering and 
Qt::partial_ordering, but
the new types can be fully BC with std.

See the details in https://bugreports.qt.io/browse/QTBUG-118913

Thanks,
Ivan


From: Development  on behalf of Thiago 
Macieira 
Sent: Friday, November 10, 2023 6:12 PM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Friday, 10 November 2023 00:11:11 PST Marc Mutz via Development wrote:
> On 09.11.23 16:28, Thiago Macieira wrote:
> > But if the symbols are globally visible (ELF visibility STV_DEFAULT)
>
> That counts as "exported", doesn't it?

Yes.

> Which leaves us with:
> - MSVC doesn't export anything by default; inline functions are,
> however, exported when the surrounding class is wholly exported
> - on all other platforms, all functions are by default "exported", but
> we emulate MSVC on those platforms by changing the default visibility to
> hidden, incl. for inline functions
>
> And my previous questions:
>
> - do our BC guarantees exist at all in the absence of
> `-fvisibility=hidden -fvisibility-inlines-hidden`?

Yes, we have to, because we don't control how the user's library is being
compiled.

> - does making the Qt and std::ordering types BC with each other not
> solve the problem in this case, too?

It does. We should really do that for Qt 7.0.

The problem is that QPartialOrdering::Unordered has been in our ABI since 6.1
and we can't change that any more.

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

[Ivan Solovev via Development]

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

Yes, we do.

Thiago wrote:
> We can also just be evil and use bit_cast

Why is that evil? Reading about std::bit_cast, this can be an option, if we
guarantee that sizeof(Qt::*_ordering) == sizeof(std::*_ordering).
Which is, probably, already true.

Thanks,
Ivan


From: Development  on behalf of Marc Mutz 
via Development 
Sent: Thursday, November 9, 2023 8:17 AM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

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

[Ivan Solovev via Development]

> I think it's acceptable for us to change the return type of a function so long
> as it's getting a new mangling.

Well, it would be easily achievable for the template methods, but not for the
inline hidden friend helper methods.
As immediate solution that comes to my mind is to add a third argument to
these methods when compiled in C++20 mode. And we could probably use
yet another macro for that. But this will just overcomplicate the things, so
I'm not a big fan of this idea.

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

So, you say that the compiler is smart enough to optimize away conversions like
`std::strong_ordering -> QStrongOrdering -> std::strong_ordering`
because the underlying integral values are the same?

I did some experiments in compiler explorer, and it seems that gcc and clang
generate similar assembly code with and without conversions.
MSVC is a bit special here, however.
See my experiments here:https://godbolt.org/z/G8Ks9v9Ks

In this case we could probably apply Marc's proposal #3 (making std::* and Qt::*
types binary compatible), and just stick to the Qt::* types in the API?

Thanks,
Ivan


From: Development  on behalf of Thiago 
Macieira 
Sent: Wednesday, November 8, 2023 4:46 PM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

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.

> 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. The impact of QAnyStringView in any API is greater.

--
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] Nominating Jaishree Vyas as approver

[Ivan Solovev via Development]

+1

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Paul 
Wicking via Development 
Sent: Wednesday, November 8, 2023 10:00 AM
To: development@qt-project.org 
Subject: [Development] Nominating Jaishree Vyas as approver

Hi everyone,

I would like to nominate Jaishree Vyas for approver rights in the Qt project.

Jai has joined TQtC as a Documentation Engineer back in February 2022. Since 
then, she's been actively making and reviewing changes. I fully trust Jai's 
judgment in reviewing and approving changes, and see her as a positive addition 
to the Qt Project.

Her authored changes are here: 
https://codereview.qt-project.org/q/owner:jaishree.vyas%40qt.io
As reviewer: 
https://codereview.qt-project.org/q/reviewer:jaishree.vyas%2540qt.io

//! Paul

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

[Ivan Solovev via Development]

Hi,

I'd like to discuss one more topic regarding the C++20 comparison.

Can we allow an `auto` return type in helper functions and the three-way
comparison implementation for the built-in types?

The idea is that these methods can return `Q*Ordering` types in C++17 mode, and
`std::*_ordering` types in C++20 mode.

The question was raised and discussed here:
https://codereview.qt-project.org/c/qt/qtbase/+/478199/comment/bbab752c_520dc684/

Now we have two controversial opinions.

The main reason to use `auto` is that it will allow us to avoid unnecessary
`std::*_ordering -> Q*Ordering -> std::*_ordering` conversions in the C++20
case, which will hopefully be the common case going forward.

The main argument agains it is the possible ODR violation when mixing C++17
and C++20 in one binary.

So, my question is - shoud we support mixing C++17 and C++20 in one binary?

Before continuing with the patches, I'd like to hear more opinions.

Thanks,
Ivan


From: Ivan Solovev 
Sent: Wednesday, October 4, 2023 11:15 AM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

So, let me give another update.

The chaing ending in https://codereview.qt-project.org/c/qt/qtbase/+/508464
passed a full pre-check in the CI.
It implements the macros in terms of helper functions ``comparesEqual()``
and ``compareThreeWay()``.
The macros are documented as internal for now.

It also provides ``qCompareThreeWay()`` as a public API for three-way
comparison.

The chain also contains examples of applying the new macros to some of the Qt
classes: QTime, QDate, QDateTime, QTimeZone, and qfloat16.

I think, Marc also started migrating more Qt classes to the new macros.

We also have a draft of a QUIP which describes how to apply the new macros
to the Qt classes: https://codereview.qt-project.org/c/meta/quips/+/490932

--

Ivan Solovev
Senior Software Engineer

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

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

From: Edward Welbourne 
Sent: Tuesday, September 26, 2023 4:31 PM
To: development@qt-project.org ; Ivan Solovev 

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

Thiago wrote:
>> See my other email: the (1) is not discoverable, teachable, or
>> particularly understandable by average C++ developers. It is not a
>> good corner of C++.

Ivan Solovev (21 September 2023 11:10) replied:
> As you correctly pointed out, most of the developers will just use
> public operator==(), and, come C++20, operator<=>().
>
> But I'd say that if someone wants to implement three-way comparison
> for their classes in C++17, then a bit better understanding of the
> language features is a reasonable expectation.

You're not thinking of all the different users of code.  The author of a
class using Qt, that opts to use our mechanism for comparisons, can
indeed be expected to understand the fancy new language features, around
which that mechanism is built.

However, the client of that code, who just wants to compare two things,
is a separate player in the game; you're also expecting them to have
that level of sophistication.  That's more of a stretch: they're just
trying to coax their template into coping with one of its parameters
being this class that someone using Qt has exposed to them in a library
they're using.  They may not even be using Qt themselves, merely
publishing a helper template that someone else is trying to use in
conjunction with some classes written using Qt.  We don't want them to
throw up their hands and tell the users of their template they don't
support use of Qt classes with their templates because "Qt does things
weirdly" (as far as they're concerned).

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)

[Ivan Solovev via Development]

So, let me give another update.

The chaing ending in https://codereview.qt-project.org/c/qt/qtbase/+/508464
passed a full pre-check in the CI.
It implements the macros in terms of helper functions ``comparesEqual()``
and ``compareThreeWay()``.
The macros are documented as internal for now.

It also provides ``qCompareThreeWay()`` as a public API for three-way
comparison.

The chain also contains examples of applying the new macros to some of the Qt
classes: QTime, QDate, QDateTime, QTimeZone, and qfloat16.

I think, Marc also started migrating more Qt classes to the new macros.

We also have a draft of a QUIP which describes how to apply the new macros
to the Qt classes: https://codereview.qt-project.org/c/meta/quips/+/490932

--

Ivan Solovev
Senior Software Engineer

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

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

From: Edward Welbourne 
Sent: Tuesday, September 26, 2023 4:31 PM
To: development@qt-project.org ; Ivan Solovev 

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

Thiago wrote:
>> See my other email: the (1) is not discoverable, teachable, or
>> particularly understandable by average C++ developers. It is not a
>> good corner of C++.

Ivan Solovev (21 September 2023 11:10) replied:
> As you correctly pointed out, most of the developers will just use
> public operator==(), and, come C++20, operator<=>().
>
> But I'd say that if someone wants to implement three-way comparison
> for their classes in C++17, then a bit better understanding of the
> language features is a reasonable expectation.

You're not thinking of all the different users of code.  The author of a
class using Qt, that opts to use our mechanism for comparisons, can
indeed be expected to understand the fancy new language features, around
which that mechanism is built.

However, the client of that code, who just wants to compare two things,
is a separate player in the game; you're also expecting them to have
that level of sophistication.  That's more of a stretch: they're just
trying to coax their template into coping with one of its parameters
being this class that someone using Qt has exposed to them in a library
they're using.  They may not even be using Qt themselves, merely
publishing a helper template that someone else is trying to use in
conjunction with some classes written using Qt.  We don't want them to
throw up their hands and tell the users of their template they don't
support use of Qt classes with their templates because "Qt does things
weirdly" (as far as they're concerned).

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)

[Ivan Solovev via Development]

I drafted a QUIP that describes how to apply C++20 comparison to Qt classes:

https://codereview.qt-project.org/c/meta/quips/+/490932

It intentionally does not mention `qCompareThreeWay()` and `qComparesEqual()`,
because these public APIs are not required for the internal implementation.

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Ivan 
Solovev via Development 
Sent: Thursday, September 21, 2023 11:10 AM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

> See my other email: the (1) is not discoverable, teachable, or particularly
> understandable by average C++ developers. It is not a good corner of C++.

As you correctly pointed out, most of the developers will just use public
operator==(), and, come C++20, operator<=>().

But I'd say that if someone wants to implement three-way comparison for their
classes in C++17, then a bit better understanding of the language features is
a reasonable expectation.

At the same time, if we use Volker's suggestion and go with `compareThreeWay`
and `comparesEqual` as the names for (1), I do not see any problems in
implementing `qCompareThreeWay` as (4).

Later we can also add `qComparesEqual` for consistency and even provide
3-arg overloads for string-like types, like Marc suggests.

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Ivan 
Solovev via Development 
Sent: Thursday, September 21, 2023 10:43 AM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

> I have just rebased the chain on top of the latest dev and fixed the issue
> with qfloat16 and -Wfloat-equal.
> Now it builds fine for me locally on Linux with GCC. Started a full pre-check
> in the CI to test other configurations.
> I'll keep an eye on the pre-check results and try to fix any other errors,
> if they occur.

The qfloat16 patch does have some issues, because MSVC behaves differently from
other compilers. That's something that needs a deeper investigation.

Meanwhile, the full CI pre-check for the previous patch in the chain has
completed successfully.
So, you can use https://codereview.qt-project.org/c/qt/qtbase/+/479395 to
test the approach.

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Thiago 
Macieira 
Sent: Thursday, September 21, 2023 2:22 AM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Wednesday, 20 September 2023 02:53:37 PDT Volker Hilsheimer via Development
wrote:
> If we can have (1), i.e.
>
> using Qt::equals;
> equals(a, b);
>
> why do we need qEquals?

See my other email: the (1) is not discoverable, teachable, or particularly
understandable by average C++ developers. It is not a good corner of C++.

(4) (the convenience function) is what users expect. Except that we don't need
it to be called qEquals, because we have an even better name for it:

operator==

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

[Ivan Solovev via Development]

> See my other email: the (1) is not discoverable, teachable, or particularly
> understandable by average C++ developers. It is not a good corner of C++.

As you correctly pointed out, most of the developers will just use public
operator==(), and, come C++20, operator<=>().

But I'd say that if someone wants to implement three-way comparison for their
classes in C++17, then a bit better understanding of the language features is
a reasonable expectation.

At the same time, if we use Volker's suggestion and go with `compareThreeWay`
and `comparesEqual` as the names for (1), I do not see any problems in
implementing `qCompareThreeWay` as (4).

Later we can also add `qComparesEqual` for consistency and even provide
3-arg overloads for string-like types, like Marc suggests.

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Ivan 
Solovev via Development 
Sent: Thursday, September 21, 2023 10:43 AM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

> I have just rebased the chain on top of the latest dev and fixed the issue
> with qfloat16 and -Wfloat-equal.
> Now it builds fine for me locally on Linux with GCC. Started a full pre-check
> in the CI to test other configurations.
> I'll keep an eye on the pre-check results and try to fix any other errors,
> if they occur.

The qfloat16 patch does have some issues, because MSVC behaves differently from
other compilers. That's something that needs a deeper investigation.

Meanwhile, the full CI pre-check for the previous patch in the chain has
completed successfully.
So, you can use https://codereview.qt-project.org/c/qt/qtbase/+/479395 to
test the approach.

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Thiago 
Macieira 
Sent: Thursday, September 21, 2023 2:22 AM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Wednesday, 20 September 2023 02:53:37 PDT Volker Hilsheimer via Development
wrote:
> If we can have (1), i.e.
>
> using Qt::equals;
> equals(a, b);
>
> why do we need qEquals?

See my other email: the (1) is not discoverable, teachable, or particularly
understandable by average C++ developers. It is not a good corner of C++.

(4) (the convenience function) is what users expect. Except that we don't need
it to be called qEquals, because we have an even better name for it:

operator==

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

[Ivan Solovev via Development]

> I have just rebased the chain on top of the latest dev and fixed the issue
> with qfloat16 and -Wfloat-equal.
> Now it builds fine for me locally on Linux with GCC. Started a full pre-check
> in the CI to test other configurations.
> I'll keep an eye on the pre-check results and try to fix any other errors,
> if they occur.

The qfloat16 patch does have some issues, because MSVC behaves differently from
other compilers. That's something that needs a deeper investigation.

Meanwhile, the full CI pre-check for the previous patch in the chain has
completed successfully.
So, you can use https://codereview.qt-project.org/c/qt/qtbase/+/479395 to
test the approach.

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Thiago 
Macieira 
Sent: Thursday, September 21, 2023 2:22 AM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Wednesday, 20 September 2023 02:53:37 PDT Volker Hilsheimer via Development
wrote:
> If we can have (1), i.e.
>
> using Qt::equals;
> equals(a, b);
>
> why do we need qEquals?

See my other email: the (1) is not discoverable, teachable, or particularly
understandable by average C++ developers. It is not a good corner of C++.

(4) (the convenience function) is what users expect. Except that we don't need
it to be called qEquals, because we have an even better name for it:

operator==

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

[Ivan Solovev via Development]

> We did _not_ deprecate qSwap().

Well, the source code shows that it _is_ deprecated:
<https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qswap.qdoc>
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qswap.qdoc

I was not able to find a documentation page for qSwap in Qt 6.5,
but here's the link to 6.2: 
https://doc.qt.io/qt-6.2/qtalgorithms-obsolete.html#qSwap

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Marc Mutz 
via Development 
Sent: Wednesday, September 20, 2023 5:25 PM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On 20.09.23 14:42, Ivan Solovev via Development wrote:
> We have deprecated qSwap()

FTR:

We did _not_ deprecate qSwap(). We banned it from inline Qt code when we
know we can use one of the other ways:

- lhs.swap(rhs);
- std::swap(lhs, rhs);
- qt_ptr_swap(lhs, rhs);

We still use it in generic code, e.g. QList().

--
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.qt.io%2F=05%7C01%7Civan.solovev%40qt.io%7C39da86d7aa2a4531845d08dbb9ee2348%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638308204676895209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=wQIWQCOhPEs0IiKdpvAgU1pOqotlP3eOSFHFr%2B7UdFM%3D=0<http://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
-- 
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)

[Ivan Solovev via Development]

Hi,

> Given the state of https://codereview.qt-project.org/c/qt/qtbase/+/481410/3 
> right now (needs rebase, doesn’t build with either C++17 or C++20 for me on 
> macOS with apple’s clang)

I have just rebased the chain on top of the latest dev and fixed the issue with 
qfloat16 and -Wfloat-equal.
Now it builds fine for me locally on Linux with GCC. Started a full pre-check 
in the CI to test other configurations.
I'll keep an eye on the pre-check results and try to fix any other errors, if 
they occur.

> O = compareThreeWay, following std::compare_three_way 
> (https://en.cppreference.com/w/cpp/utility/compare/compare_three_way)
> E = comparesEqual
>
> The vast majority of code will use operators to compare two objects.
> Code that somehow needs the concept spelled out can type it out as well.
> In contrast to `swap` we don’t need to be short here, given that the 
> operator-shorthand exists.

Nice suggestion, thanks! Works for me!

> why do we need qEquals?

Actually, I have the same question. That's why I wrote that we might decide to 
not provide (4) at all.
We have deprecated qSwap() and explicitly recommend using

using std::swap;
swap(lhs, rhs);

instead. So why should we act differently for comparison?

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Volker 
Hilsheimer via Development 
Sent: Wednesday, September 20, 2023 11:53 AM
To: Marc Mutz ; development@qt-project.org 

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


On 19 Sep 2023, at 15:49, Marc Mutz via Development 
 wrote:
So I ask: Please let us roll out the framework with one of
equal/eq/order/ordering/cmp (your choice, but quickly!), to set a status
quo against which to benchmark any potentially-superior solutions, and
then the ML can finish bikesheddding and if the discussion yields
something better, I think I speak for Ivan, too, when I say that we're
committed to porting to that.

Thanks,
Marc


Given the state of https://codereview.qt-project.org/c/qt/qtbase/+/481410/3 
right now (needs rebase, doesn’t build with either C++17 or C++20 for me on 
macOS with apple’s clang), my suggestion would be to go “very explicit" with 
the names for O and E, at least for the time being.

O = compareThreeWay, following std::compare_three_way 
(https://en.cppreference.com/w/cpp/utility/compare/compare_three_way)
E = comparesEqual


The vast majority of code will use operators to compare two objects. Code that 
somehow needs the concept spelled out can type it out as well. In contrast to 
`swap` we don’t need to be short here, given that the operator-shorthand exists.

Once the chain of commits is up-to-date it will be easier to play around with 
alternatives, to see if we can come up with a technical solution that allows us 
to use `equals` and `compare` as names for E and O, as those are established 
APIs in Qt.


You lost me here, but I assume that you're talking about what I call
(4). There must be _one_ global template. It calls (2) or (3) via (1).
Everything else is a novel idea that must argue against 30 years of C++
and 30 years of Qt experience. qFoo would be that (4). A class-static
cannot be that (4).

Yes, I’m not questioning that we need Qt::equals. But do we need (4)? you 
marked it as optional yourself.

If we can have (1), i.e.

using Qt::equals;
equals(a, b);

why do we need qEquals?

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

[Ivan Solovev via Development]

have a q/q_/qt_ prefix, but we might want that,
anyway, so not really a problem there. But this has the same problem
with 100s of overloads and the compiler printing them all on error. In
addition, I _think_ (and the language lawyers can speak up whether I'm
right or wrong), name lookup will go up the scopes, find (one of the)
`swap`s at the global scope and stop there. Since it found something, it
will not consider ADL.

If you have more, let's hear it.

Thanks,
Marc

On 17.08.23 19:41, Thiago Macieira wrote:
> On Monday, 14 August 2023 03:16:37 PDT Ivan Solovev via Development wrote:
>>> What I meant is that the product API of using the macros are the set of
>>> operators. The methods that those operators called are not API and users
>>> are not expected to use them in their code. In fact, if conflicting names
>>> are a problem, then we should uglify the names we're asking for in the
>>> macros by inserting a "q_" or "qt_" prefix.
>>>
>>> This means C++17 users are able to use all operators to produce a boolean
>>> result, but can't get a QXxxOrdering result with homogeneous API from the
>>> macros.
>>
>> The new macros are supposed to be publicly available. This means that the
>> users will be able to use them in their custom classes to implement the
>> unified comparison behavior between C++17 and C++20.
>>
>> This means that the users will need to provide their implementations of
>> the helper methods. The idea is to explicitly mention it in the docs,
>> so the methods cannot be considered "Qt internal" anymore.
>> Can we use the "q_" or "qt_" prefix for these helper functions in this case?
>
> The methods aren't "Qt internal" but they they don't have to be API either for
> those libraries any more than they have to for us. They are used by library
> implementers (like us), so an uglier name is not a big deal.
>
> But maybe we should opt for a name like qHash and the older qLess.
>
>> Or do you suggest making the macros Qt-private? Not that we *really* can
>> do it, because the macros are exposed in public headers, but we can at least
>> hide the documentation, and do not advertise the macros...
>> But IMO such decision would significantly decrease the value of the new
>> feature.
>
> I'm unsure. How widely used is this going to be even inside Qt? Have you found
> any use for it inside Qt Creator?
>
> I can actually see this more used in the KF6 libraries than in Qt Creator
> because they are libraries (Qt Creator has some, but they are all internal
> with in-tree users). We may want to keep them documented with \internal for
> the first release and take a look if we find uses for it outside of Qt. That 
> way
> we can also collect any issues with colliding symbol names and adapt them
> before having to guarantee source compatibility.
>
>>> We still need *some* level of public API to produce ordering results
>>> because users will need those methods to produce their own comparison
>>> functions, such as composing on top of our string or date/time classes.
>>> If they want to also be compatible with C++17, then they can't use the
>>> spaceship, and instead they will need to call a named function of some
>>> sorts. If we are going to expose API, then said API must have proper
>>> names and thus must be "equals" and "compare".
>>
>> The initial idea was that the helper functions could also become the public
>> API for producing ordering results. IIUC, that's also why Marc suggested to
>> make them hidden friends. Using private 2-arg static function would work for
>> the comparison operators but wouldn't work as a public API. Hidden friends
>> will work for both cases.
>
> And I think it's a good idea for there to be a public function users can use
> in C++17 mode. But as I said, that requires them to have proper names. Whether
> they are the same functions that the macros call is up for debate. They don't
> have to be: one set can call the other without trouble, just with a bit of
> boilerplate.
>
> The question to answer is whether we want to support users writing generic
> code in C++17 mode (i.e., without the spaceship). I don't particularly think
> it's necessary and thus don't think it compels us to make compromises in our
> API for this use-case. Third party code would either need to require C++20 or
> forego the ability to be generic. So like above: I think we need to know
> whether there's any real use out there of this.
>
> If we do think we should provide a generic API, then I'd argue such API should
> be namespaced with a "q" prefix: qEquals

Re: [Development] How to document API only deprecated in future Qt versions

[Ivan Solovev via Development]

Hi,

> I see two fixes for this;
> - Keep the documentation API fix separate from the header file fix, and only 
> merge it when Qt 6.9 got branched.
> This requires 'someone' to follow up on these things, though, more than a 
> year after the deprecation decision has been made.

This approach will help to solve some inconsistencies that I will describe 
below, but I do not believe that it will work in practice.
We will simply forget about the doc udpates.

> - Deprecate the API already _in the documentation_ for 6.6, but only follow 
> up with the compiler warning in Qt 6.10.

This might lead to confusion in some corner cases.
For example, when doing a Qt build with QT_DISABLE_DEPRECATED_UP_TO.
Based on the documentation, the users will expect that the function is removed 
from the build, but it will still be there.
Not sure how critical this is in practice.


We could solve the problem if we could automate the first suggestion - create 
some script that will recognize
the QT_DEPRECATED_VERSION macro (and all its variations) for the specific Qt 
version and adjust the docs accordingly.
Probably QDoc could be extended to support a feature like this.
Then, simply running this script to find and fix all deprecations in Qt MAJ.MIN 
before creating the MAJ.MIN.0 branch should help.

I'm not sure how feasible it would be in practice, though.

Best regards,
Ivan

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Kai Köhne 
via Development 
Sent: Friday, September 15, 2023 9:36 AM
To: qt-development 
Subject: [Development] How to document API only deprecated in future Qt versions

Hi,

Eddy and Ivan did a great job in documenting how to formally deprecate API in 
at https://wiki.qt.io/Deprecation . It's not only giving you the right macros 
to use ... it also contains some suggestions for which version to do it.

About the Qt version to deprecate an API for, the page says:

 When deprecating an old API in favor of a new one, it is a kindness to 
client code
 maintainers to set the version at which the deprecation takes effect to a 
future version,
 such as three minor versions after the new API was added, to give ample 
time to adapt
 to it. All the same, you must prepare all of Qt's code for the transition 
promptly, as if
 the deprecation took effect as soon as its commit integrated.

I see why this 'conservative' approach is beneficial. Projects like Qt Creator 
tend to support multiple Qt versions, and immediately deprecating an old API in 
the same version the replacement API got added makes this hard to handle.\

Anyhow, it creates a challenge for documentation. Take e.g.

https://doc-snapshots.qt.io/qt6-6.6/qtfuture-obsolete.html

The methods are formally marked as deprecated for Qt 6.10. But the methods are 
already in the '-obsolete' page for Qt 6.6, which leaves the API in a weird 
in-between state.

I see two fixes for this;
- Keep the documentation API fix separate from the header file fix, and only 
merge it when Qt 6.9 got branched. This requires 'someone' to follow up on 
these things, though, more than a year after the deprecation decision has been 
made.
- Deprecate the API already _in the documentation_ for 6.6, but only follow up 
with the compiler warning in Qt 6.10.

I'm actually in favor of the second approach; documentation is mostly read when 
writing _new_ code, and that should already be written with the new API. But 
it's not something we've done so far, IMO.

Do you agree?

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin
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
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: (re)move qt5.git/_clang-format

[Ivan Solovev via Development]

> I would therefore propose to remove the file from qt5.git:

+1 from my side.
I believe I simply do not have the clang-format tool installed on my system,
because it usually breaks the formatting of the patches, not improves them.

> One way to address these problems, especially for new devs or drive-by
> contributions, is stating clearly in the wiki page:
> "use clang-format, it should get you at least half way there, but you still
> should/must also override it to match the style of surrounding code, as much 
> as
> possible, in the file(s) you're editing, that's kinder to reviewers".

The problem is that we have a pre-commit (I believe) git-hook, which checks the
formatting and nags if it does not match to what we have in the _clang-format 
file.
This basically forces​ the new or drive-by contributors to submit the patch 
with an
incorrect formatting, which then leads to a bunch of review comments about 
code-style.

I think that it's better to give no hints, rather than misleading hints.

Best regards,
Ivan

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Ulf Hermann 
via Development 
Sent: Wednesday, September 13, 2023 8:54 AM
To: development@qt-project.org 
Subject: Re: [Development] Proposal: (re)move qt5.git/_clang-format

> There _is_ consensus. It's in the wiki. And in older modules not
> infected by the _clang-format file. Discussions arise because
> of .clang-format, not despite it. Afaict, there never was a discussion
> about how faithful the _clang-format represents the Qt style before it
> was added. If there was _any_ attempt at the above-mentioned litmus
> test, the template<> issue and others would have been detected immediately.

Unfortunately the consensus is weak on the most jarring problem, and
that happens to be one that the automatic formatters I know are utter
rubbish at:

Where do you break the line and how much white space do you indent in
various situations? For example:

* long lists of arguments list to a function (call or declaration)
* nested template parameters, possibly with defaults
* template arguments
* lists of partially specialized template parameters
* initializer lists (possibly nested)
* ternary operators with outsized "hands"
* constructor-initializers
* lambdas, potentially nested
* nested boolean or arithmetic expressions with or without parentheses
* and then combine all of those

I find myself constantly re-indenting things based on some unwritten
rules I make up myself. I would be fine with an automatic indentation
that produces somewhat readable code, but what I get is frequently an
indentation to column 205 or similar for no obvious reason.

Yes, it often helps to use additional temporaries so that your lines are
not as large to begin with. However, that also increases the cognitive
load when reading it as you then have to carefully determine if the
introduction of the temporary changes semantics. For example, is the
temporary moved or copied? Does the extracted template construction
allow things the inline one was not meant to allow? etc.

All the other stuff you may format for is trivial in comparison because
it only involves adding or removing few characters here or there. With
some practice it takes up rather little time, even when done manually.
The indentation, however, requires shifting around large bodies of white
space, which is quite annoying in the editors I know.

best regards,
Ulf
--
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] Nominating Ahmad Samir for approver

[Ivan Solovev via Development]

+1

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Mårten 
Nordheim via Development 
Sent: Monday, September 11, 2023 11:29 AM
To: development@qt-project.org ; Volker Hilsheimer 

Subject: Re: [Development] Nominating Ahmad Samir for approver

+1

Mårten


From: Development  on behalf of Volker 
Hilsheimer via Development 
Sent: Monday, September 11, 2023 11:16
To: development@qt-project.org
Subject: [Development] Nominating Ahmad Samir for approver

Hello all,

I would like to nominate Ahmad Samir for approver rights in the Qt project.

For many months, Ahmad has produced a consistent flow of good contributions and 
reviews to Qt:

Changes owned:
* https://codereview.qt-project.org/q/owner:a.samirh78%2540gmail.com

Changes commented/voted on:
* 
https://codereview.qt-project.org/q/commentby:a.samirh78%2540gmail.com+-owner:a.samirh78%2540gmail.com


Cheers,
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
-- 
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)

[Ivan Solovev via Development]

I'm now re-reading the discussion, and I think that I missed one thing
previously, so let me comment on that.

> What I meant is that the product API of using the macros are the set of
> operators. The methods that those operators called are not API and users are
> not expected to use them in their code. In fact, if conflicting names are a
> problem, then we should uglify the names we're asking for in the macros by
> inserting a "q_" or "qt_" prefix.
>
> This means C++17 users are able to use all operators to produce a boolean
> result, but can't get a QXxxOrdering result with homogeneous API from the
> macros.

The new macros are supposed to be publicly available. This means that the
users will be able to use them in their custom classes to implement the
unified comparison behavior between C++17 and C++20.

This means that the users will need to provide their implementations of
the helper methods. The idea is to explicitly mention it in the docs,
so the methods cannot be considered "Qt internal" anymore.
Can we use the "q_" or "qt_" prefix for these helper functions in this case?

Or do you suggest making the macros Qt-private? Not that we *really* can
do it, because the macros are exposed in public headers, but we can at least
hide the documentation, and do not advertise the macros...
But IMO such decision would significantly decrease the value of the new
feature.

> We still need *some* level of public API to produce ordering results because
> users will need those methods to produce their own comparison functions, such
> as composing on top of our string or date/time classes. If they want to also
> be compatible with C++17, then they can't use the spaceship, and instead they
> will need to call a named function of some sorts. If we are going to expose
> API, then said API must have proper names and thus must be "equals" and
> "compare".

The initial idea was that the helper functions could also become the public
API for producing ordering results. IIUC, that's also why Marc suggested to
make them hidden friends. Using private 2-arg static function would work for
the comparison operators but wouldn't work as a public API. Hidden friends
will work for both cases.

If we advertise only the public API which is not supported by the macros,
then the users will still need to implement all six (or 12 in case of
mixed-type comparison) relational operators instead of just calling one macro
and implementing two helper functions.

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Thiago 
Macieira 
Sent: Tuesday, August 1, 2023 5:11 PM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Tuesday, 1 August 2023 01:55:05 PDT Ivan Solovev via Development wrote:
> > BTW, this needs to integrate with QEqualityOperatorForType and
> > QLessThanOperatorForType in qmetatype.h. I don't think there's any work
> > for
> > you other than verifying.
>
> I was not even aware of them, thanks! A brief look at the code shows that
> they shouldn't be affected, but I'll update the Jira ticket to keep them
> in mind.

I wasn't either. I went looking for qLess, which existed for Qt 3, 4 and 5 for
Q(Value)Map, and found them.

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

[Ivan Solovev via Development]

> Every pair? Under what conditions do we need to implement heterogeneous
> comparisons, outside of the primitives?

Well, it was not a very precise wording from my side.
What I mean is that we need to handle every class with existing relational
operators. Which looks like a lot of work, and adding a new function overload
on top of it makes it even worse.
I also had in mind cases like "QPoint vs QPointF" or "QSize vs QSizeF",
but I now see that we do not explicitly provide operators for such comparisons.
Instead, we rely on the implicit constructors to do the conversion.

> BTW, this needs to integrate with QEqualityOperatorForType and
> QLessThanOperatorForType in qmetatype.h. I don't think there's any work for
> you other than verifying.

I was not even aware of them, thanks! A brief look at the code shows that
they shouldn't be affected, but I'll update the Jira ticket to keep them
in mind.

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Edward 
Welbourne via Development 
Sent: Tuesday, August 1, 2023 9:17 AM
To: Macieira, Thiago ; development@qt-project.org 

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

On Monday, 31 July 2023 02:36:41 PDT Ivan Solovev via Development wrote:
>> Basically, what you suggest is that for every pair of comparable Qt
>> types we would need to double the amount of work that we do - provide
>> not only the helper functions for the macros, but also the overload
>> for some public functions for the end-users.

Thiago Macieira (31 July 2023 17:23) replied:
> Every pair? Under what conditions do we need to implement
> heterogeneous comparisons, outside of the primitives? Even with the
> primitives, I don't see more than a handful of heterogeneous, between
> integers and floating point, plus a few other dispatchers to avoid
> ambiguous lookups for integer to integer.

There'd also be our plethora of string types - but still, indeed, only a
fairly limited set of cross-type comparisons.

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

[Ivan Solovev via Development]

> What I meant is that the product API of using the macros are the set of
> operators. The methods that those operators called are not API and users are
> not expected to use them in their code. In fact, if conflicting names are a
> problem, then we should uglify the names we're asking for in the macros by
> inserting a "q_" or "qt_" prefix.

I do not completely agree with that, see my arguments below.

> We still need *some* level of public API to produce ordering results because
> users will need those methods to produce their own comparison functions, such
> as composing on top of our string or date/time classes. If they want to also
> be compatible with C++17, then they can't use the spaceship, and instead they
> will need to call a named function of some sorts.

Right, totally agree with this part.

> If we are going to expose
> API, then said API must have proper names and thus must be "equals" and
> "compare".
>
> But again, these do not need to be the functions that the macros call
> directly. The macros may call adaptor functions with ugly names.

What I cannot understand is why we should duplicate the functions? It would
be much easier if we could use the same functions both for macros and the
user-specific code.

Basically, what you suggest is that for every pair of comparable Qt types
we would need to double the amount of work that we do - provide not only
the helper functions for the macros, but also the overload for some
public functions for the end-users.

Of course, we could try to simplify it. I already started to introduce
Qt::order() overloads for built-in types in [0].
So, we could probably provide a general case like this:

template 
auto order(const L , const R ) noexcept
{
// or any other uglified name that we choose
return qt_order(lhs, rhs);
}

and just let the template fail if qt_order() is not defined for L and R.

With such approach, we could use qt_equals() and qt_compare() as helper
functions, and Qt::equals() and Qt::compare() as public API for the users.

But then, if we use qt_*() functions, their names will not clash with any
of the existing APIs, and we can just let the end-users use these
functions directly.

[0]: https://codereview.qt-project.org/c/qt/qtbase/+/478199

--

Ivan Solovev
Senior Software Engineer

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

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


From: Thiago Macieira
Sent: Wednesday, July 26, 2023 5:18 PM
To: development@qt-project.org
Cc: Ivan Solovev
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Wednesday, 26 July 2023 02:58:51 PDT Ivan Solovev via Development wrote:
> > That means it can't be used in ADL contexts without scope qualifications,
> > but I don't see that as an API requirement. The API should be the
> > operators.
> We introduce new public macros, which means that users will be using them in
> their custom classes in order to achieve the same unified comparison
> behavior between C++17 and C++20.
> This means that the users will have to implement the helper functions
> required for these macros. I agree that for the equal()/equals() helper
> function, the op==() and op!=() are mostly usable.
> But what about the order()/compare() function? I assume that the users would
> NOT be able to use op<=>(), because they will write C++17-compatible code.
> And testing for Unordered in terms of C++17 relational operators looks like
> an unnecessarily large amount of code, especially if we already have
> written this code for them. So why not just let them use it?
> Of course, you can argue that they can use the public APIs directly (if they
> exist). But what if the user develops a generic class?

What I meant is that the product API of using the macros are the set of
operators. The methods that those operators called are not API and users are
not expected to use them in their code. In fact, if conflicting names are a
problem, then we should uglify the names we're asking for in the macros by
inserting a "q_" or "qt_" prefix.

This means C++17 users are able to use all operators to produce a boolean
result, but can't get a QXxxOrdering result with homogeneous API from the
macros.

We still need *some* level of public API to produce ordering results because
users will need those methods to produce their own comparison functions, such
as composing on top of our string or date/time classes. If they want to also
be compatible with C++17, then they can't use the spaceship, and instead they
will need to call a named function of some sorts. If we are going to expose
API, then sa

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

[Ivan Solovev via Development]

> Ah, I see. It's not an ambiguous overload problem because the hidden friend is
> not even part of the overload set in the first place. That can be solved by
> promoting the function from hidden friend to static member, either as public
> or private, depending on the implementer's choice.
>
> That means it can't be used in ADL contexts without scope qualifications, but 
> I
> don't see that as an API requirement. The API should be the operators.

We introduce new public macros, which means that users will be using them in
their custom classes in order to achieve the same unified comparison behavior
between C++17 and C++20.
This means that the users will have to implement the helper functions required
for these macros. I agree that for the equal()/equals() helper function, the
op==() and op!=() are mostly usable.
But what about the order()/compare() function? I assume that the users would
NOT be able to use op<=>(), because they will write C++17-compatible code.
And testing for Unordered in terms of C++17 relational operators looks like an
unnecessarily large amount of code, especially if we already have written this
code for them. So why not just let them use it?
Of course, you can argue that they can use the public APIs directly (if they
exist). But what if the user develops a generic class?

What we can do is to have both private/public static two-arg member and a
hidden friend, which would simply call the static method. We will have to
apply this hack only to the classes that already have public APIs with the
clashing names. For other classes we can just use hidden friends directly.

> You forgot the <=> 0 here. Comparing an int with 0 through the spaceship
> operator produces a std::strong_ordering result. And comparing a
> std::strong_ordering with 0 via the spaceship returns itself too.
>
> https://gcc.godbolt.org/z/ebKe8Eb3a
>
> This works for weak_ordering too. For partial_ordering, the case of unordered
> needs to be handled explicitly, so I'd instead require that the called
> function return either std::partial_ordering or QPartialOrdering, nothing
> else.

Well, the idea was to avoid unnecessary operations, and basically optimize
operator<=>() to simply call the helper function in C++20 case.

But anyway, that's a nice approach, and I should consider using it in my
patches. Specially if it allows us to "unblock" compare() as a name for the
helper function.

--

Ivan Solovev
Senior Software Engineer

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

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


From: Thiago Macieira
Sent: Tuesday, July 25, 2023 4:42 PM
To: development@qt-project.org
Cc: Ivan Solovev
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Tuesday, 25 July 2023 01:42:42 PDT Ivan Solovev via Development wrote:
> > And why is that a problem? So long as the proper overload exists, it'll be
> > called. There's only a problem if the overloads are ambiguous.
>
> The problem is that there might be no "proper" overload, but the compiler
> would still try to use the public API methods, ignoring the hidden friend
> with a correct signature. That's what I tried to illustrate with the links
> from my previous email.

Ah, I see. It's not an ambiguous overload problem because the hidden friend is
not even part of the overload set in the first place. That can be solved by
promoting the function from hidden friend to static member, either as public
or private, depending on the implementer's choice.

That means it can't be used in ADL contexts without scope qualifications, but I
don't see that as an API requirement. The API should be the operators.

> Also, we have inconsistency among our classes, as some of them use two-arg
> static equals(), and others use one-arg non-static equals().

That doesn't seem to be a problem. If we can't make the macros work with
either, then we can simply add another equals to match the one we want,
adapting to the one we don't. That is, we'd probably add a static equals that
calls the non-static one if the latter is already public API and is in the
ABI.

> In my patch[0] I introduce several helper macros that use helper functions
> to provide the actual implementation.
> Since we are talking about "equal()/equals()", let's take
> Q_DECLARE_EQUALITY_COMPARABLE as an example. Omitting all the details,
> and supposing that we use "equals" as a helepr function name, it expands
> into something like this:
>
> friend bool operator==(const MyType , const MyType ) noexcept
> { return equals(lhs, rhs); }
>
> As you can see, we selected the two-arg version of the helper

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

[Ivan Solovev via Development]

> Then don't use that as the hidden friend. The public API requirements take
> precedence. So long as the problem is not insurmountable, we should make the
> effort to have a clean API because we'll be stuck with it for the next 10
> years.
>
> > The public methods, in turn, are actually an issue, because the compiler
> > will
> > try to use them instead of a defined hidden friend, even if the number of
> > arguments or their types do not match.
>
> And why is that a problem? So long as the proper overload exists, it'll be
> called. There's only a problem if the overloads are ambiguous.

The problem is that there might be no "proper" overload, but the compiler
would still try to use the public API methods, ignoring the hidden friend
with a correct signature. That's what I tried to illustrate with the links
from my previous email.

Also, we have inconsistency among our classes, as some of them use two-arg 
static
equals(), and others use one-arg non-static equals().

In my patch[0] I introduce several helper macros that use helper functions
to provide the actual implementation.
Since we are talking about "equal()/equals()", let's take
Q_DECLARE_EQUALITY_COMPARABLE as an example. Omitting all the details,
and supposing that we use "equals" as a helepr function name, it expands into
something like this:

friend bool operator==(const MyType , const MyType ) noexcept
{ return equals(lhs, rhs); }

As you can see, we selected the two-arg version of the helper function.
This will work without any additional changes for the classes like
QBluetoothDeviceInfo, which has a private static two-arg equals[1], but would
fail for classes like QLocale, because it has a one-arg non-static equals[2].

I could re-write the macro to use the one-arg version (which does not make
much sense for me), but that would just "reverse" the problem.

And in any case, none of the existing public APIs would be able to work with
the generic code. And I keep repeating that it's something that we want to
provide for our users as building blocks for implementing three-way-comparison
with C++17.

[0]: https://codereview.qt-project.org/c/qt/qtbase/+/475447
[1]: 
https://github.com/qt/qtconnectivity/blob/dev/src/bluetooth/qbluetoothdeviceinfo.h#L233
[2]: https://github.com/qt/qtbase/blob/dev/src/corelib/text/qlocale.h#L1125

> As I said: we should strive for the proper naming.
>
> This also applies to the ordering function be called "compare".

The problem with "compare" is the pre-existing QString::compare(), which
returns an int.
Again, let's consider an example macro from [0].
Let's take Q_DECLARE_STRONGLY_ORDERED, which expands into all 6 relational
operators under C++17. I'll consider only operator>() and operator<() here for 
simplicity:

friend bool operator<(const MyType , const MyType ) noexcept
{ return order(lhs, rhs) == QStrongOrdering::Less; }
friend bool operator>(const MyType , const MyType ) noexcept
{ return order(lhs, rhs) == QStrongOrdering::Greater; }

Here we expect that the order() function returns one of the Q*Ordering types.

I agree that it can be re-written to work with the compare() function
returning an int:

friend bool operator<(const MyType , const MyType ) noexcept
{ return compare(lhs, rhs) < 0; }
friend bool operator>(const MyType , const MyType ) noexcept
{ return compare(lhs, rhs) > 0; }

HOWEVER, that will work ONLY for C++17.

For C++20 we want the Q_DECLARE_STRONGLY_ORDERED marco to simply expand into
operator<=>():

friend auto operator<=>(const MyType , const MyType ) noexcept
{ return order(lhs, rhs); }

Obviously, we want the helper function to remain the same for both C++17 and 
C++20.
I don't see how we can re-use a compare() function returning an int here.

Best regards,

--

Ivan Solovev
Senior Software Engineer

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

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


From: Thiago Macieira
Sent: Tuesday, July 25, 2023 2:11 AM
To: development@qt-project.org
Cc: Ivan Solovev
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Monday, 24 July 2023 05:34:58 PDT Ivan Solovev via Development wrote:
> > Why doesn't "equals" work?
> >
> > We've been over this in the code review: our current naming conventions
> > would dictate "equals" even for two arguments, as the most common
> > phrasing is "A equals B" instead of "A and B equal". When you compare
> > things, you always compare at a minimum two of them, so there being two
> > is implied by the act of comparing

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

[Ivan Solovev via Development]

Hi,

let me try to revive the discussion, because we want the C++20 comparison task
to be finished for Qt 6.7.

> > And we have the calling convention:
> > lhs.O(rhs);
> > Qt::O(lhs, rhs); // if you know the type
> >
> > using Qt::O;
> > O(lhs, rhs);
> > . // if you don't
>
> I don't think this is necessary. I would prefer if that were only allowed
> through op<=>.
>
> C++17-constrained users would therefore need to know the types in question,
> know what the "O" function is called and how to call it (static vs non-
> static). And if it isn't public at all, then you're limited to the traditional
> relational operators (op<, op<=, op> and op>=). Mind you, we're not breaking
> those users in any way; we're simply not adding extra API for them.

The whole idea of the C++20 comparison epic is to provide a unified comparison
behavior between C++17 and C++20 *and* to provide the three-way-comparison
features to the Qt users who are still stuck with C++17.

As it was discussed in another mailing threads, we are not planning to demand
C++20 until Qt 6.9 ([0] and [1]), and we will also have one more LTS version
(Qt 6.8) based on C++17.

Considering all the above, I think it's important to give our users the
possibility to implement three-way-comparison in their custom classes.
And here the equal() and order() functions would be the building blocks that
we provide for it. In my opinion, this is the main reason to allows things
like
using Qt::func;
func(lhs, rhs);

[0]: https://lists.qt-project.org/pipermail/development/2023-May/043812.html
[1]: https://lists.qt-project.org/pipermail/development/2023-May/043865.html

Now, regarding the helper function naming:

> Why doesn't "equals" work?
>
> We've been over this in the code review: our current naming conventions would
> dictate "equals" even for two arguments, as the most common phrasing is "A
> equals B" instead of "A and B equal". When you compare things, you always
> compare at a minimum two of them, so there being two is implied by the act of
> comparing anyway. And I don't see why we can't provide both static and non-
> static members, like QString::compare does

IIUC, the main problem that Marc has in mind is that the existing class member
equals() would conflict with the two-arg hidden friend equals(), which we would
use as a helper for operator==() and operator!=().

Grepping through all Qt sources, I see quite a lot of usages of one- or two-arg
equals() methods, however most of them are private.
The private methods are not an issue, because we can use
QT__REMOVED_SINCE to get rid of them.

The public methods, in turn, are actually an issue, because the compiler will
try to use them instead of a defined hidden friend, even if the number of
arguments or their types do not match.
See here for an example:
https://godbolt.org/z/qW6c9dPY8 (two-arg public equals)
https://godbolt.org/z/d19qvxv79 (one-arg public equals)

However, I managed to make it work introducing an extra private static method:
https://godbolt.org/z/3Ycf5Kh1Y (two-arg public equals)
https://godbolt.org/z/nv9jK4eqv (one-arg public equals)

This is not an ideal solution, because, as you can see in the output, the
operator==() explicitly calls the private static method instead of the hidden
friend. However, the generic code also works (this time calling hidden friend,
which forwards to private static).

Probably this approach would allow us to use "equals()" as a name for the E
function.
What do you think?

Best regards,

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Thiago 
Macieira 
Sent: Wednesday, June 14, 2023 6:16 PM
To: development@qt-project.org 
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Wednesday, 14 June 2023 01:52:49 PDT Marc Mutz via Development wrote:
> == Why E _and_ O? ==
>
> The reason we need E _and_ O for ordered types instead of just O is that
> O needs to order the lhs w.r.t. the rhs, which generally involves
> looking at all the state of the objects whereas E just needs to find
> _one_ difference to be able to quickly return false. E.g., a container
> can do
>
>  bool E(~~~ lhs, ~~~ rhs) {
>  if (lhs.size() != rhs.size()) return false; // O cannot do this!
>  
>  }
>
> This is a very important optimization (and one reason why L1 string
> literals are going to stay and not be replaced with UTF-8 ones: L1 op
> UTF-16 _can_ use the size() short-cut while UTF-8 op UTF-16 cannot).

It's also why glibc added __memcmpeq and GCC and Clang can generate a call to
that. Same reason why I added QtPrivate::equalStrings() different from

Re: [Development] Module maintainers: QT_NO_CONTEXTLESS_CONNECT in your modules

[Ivan Solovev via Development]

Hi,

> Second, it's also easy to forget that since there's no receiver/context,
> the connection is always forced to be *direct*, which complicates things
> if multiple threads are involved.

I'm not a module maintainer, but I remember fixing a bug in Qt Bluetooth which 
was caused by exactly this issue.
And I must admit that it was rather difficult to detect it.

So, I think that this macro is useful.

Best regards,

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Giuseppe 
D'Angelo via Development 
Sent: Monday, July 10, 2023 6:02 PM
To: development@qt-project.org 
Subject: [Development] Module maintainers: QT_NO_CONTEXTLESS_CONNECT in your 
modules

Hi,

https://codereview.qt-project.org/c/qt/qtbase/+/487560 introduces
QT_NO_CONTEXTLESS_CONNECT , a macro that disables the 3-arguments
connect -- in other words, it disables the

>   QObject::connect(sender, signal, functor)

overload, leaving only 4/5 argument(s) overloads

> QObject::connect(sender, signal, receiver/context, functor/slot, (type))


as well as the string-based connect().


The reason for NOT using the 3-args overload is that it is error prone.

For starters, it makes it hard to reason about the lifetime of such a
connection. It makes it very easy to connect to lambdas that capture
some local state in the receiver, but when the receiver is destroyed,
the connection isn't automatically disconnected (therefore, if the
signal is emitted, the program will crash). Fixing this may or may not
be straightforward, depending on how much state is captured.

Second, it's also easy to forget that since there's no receiver/context,
the connection is always forced to be *direct*, which complicates things
if multiple threads are involved.

--

I'm about to enable the macro for (most) of QtBase:

https://codereview.qt-project.org/c/qt/qtbase/+/489232

I've also done the exercise of enabling it for qtdeclarative (patches
pending) and qttools (merged), but there's simply too much code out
there that *still* uses it. As I said above, fixes are not always
obvious (sometimes it's very unclear who the "receiver" is).

--

Since this is ultimately a code style issue, I'd like to leave the
decision with the module maintainers regarding whether or not enable
QT_NO_CONTEXTLESS_CONNECT for their own modules. Ideally, however, we
should enable it in headersclean, so please make at least those not
contain 3-args connect().


Opinions? Objections?


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

Re: [Development] C++20 ctor-level [[nodiscard]] (was: Re: C++20 @ Qt)

[Ivan Solovev via Development]

> (*)  That macro that does nothing until C++20 anyway, so I’d also add the 
> support for the optional string-literal that C++20 also introduces..

Our tests actually show that this macro provides an expected warning on most of 
the compilers that we use in the CI, even in C++17 mode.
IIRC, in my tests I only had issues with INTEGRITY, GCC 9.3.1 on OpenSuse 15.4, 
and QCC 8.3.0 on QNX.
For these platforms the macro currently does nothing.

Best regards,
Ivan

--

Ivan Solovev
Senior Software Engineer

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

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

From: Development  on behalf of Volker 
Hilsheimer via Development 
Sent: Sunday, June 18, 2023 2:59 PM
To: Macieira, Thiago ; development@qt-project.org 

Subject: Re: [Development] C++20 ctor-level [[nodiscard]] (was: Re: C++20 @ Qt)

> On 16 Jun 2023, at 20:25, Thiago Macieira  wrote:
>
> On Friday, 16 June 2023 11:05:30 PDT Giuseppe D'Angelo via Development wrote:
>> On 16/06/2023 18:00, Thiago Macieira wrote:
>>> On Friday, 16 June 2023 01:06:33 PDT Stephen Kelly wrote:
 Make sure you're not hitting

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96117
>>>
>>> We are indeed hitting that. But there's nothing we can currently do about
>>> it.
>> Why can't we turn Q_DECL_EXPORT to [[gnu::visibility("default")]] to
>> work around the bug?
>
> Marc to comment, but I don't think it solves the MSVC problem we're also
> hitting, which means that adding no_discard to classes is still a problem.
> Therefore, there's no point in changing our Q_DECL_EXPORT.
>
> We'd also need to change *all* our __attributes__, not just the visibility
> ones, and we still risk breaking users' code that have __attributes__ in their
> classes and especially functions but use Q_DECL_EXPORT.
>
> Think of declarations like:
>
> [[nodiscard]] Q_CORE_EXPORT Q_DECL_PURE_FUNCTION qsizetype qustrlen(const
> char16_t *str) noexcept;

My take-away is: What we should care about is the small set of RAII classes 
where the side-effects of the constructor and destructor are the whole point. 
E.g. it would be good if we can reliably encourage a compiler warning for 
Listing 1:

QMutexLocker();

because that mistake is easily made and positively harmful.

>From what I get out of this recap of the state of standard and compilers, it 
>seems that we can't: class-level [[nodiscard]] doesn’t give us that warning 
>(reliably, on all compilers), while it does give us warnings that we might not 
>want (ie when not using the return value of a function). And it’s problematic 
>to use with whole-sale exported classes; but since RAII types like 
>QMutexLocker shouldn’t be exported whole-sale anyway, that’s perhaps not a 
>problem in practice.

So, agree with Marc’s proposal to drop (or at least not add any new) usage of 
class-level [[nodiscard]], and to use constructor-level [[nodiscard]] instead 
via Q_NODISCARD_CTOR (*). This still makes it a good service to Qt users that 
are on C++ 20. For everyone else, things are as they were before.

For all other types, I think it’s quite alright that users writing code as per 
Marc's Listings 2-4:

   QSize(12, 32);

have to figure out the “hard" way why there is no variable to pass into the 
function that they were planning on calling.

Volker

(*)  That macro that does nothing until C++20 anyway, so I’d also add the 
support for the optional string-literal that C++20 also introduces..


--
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] Meeting minutes from Qt Release Team meeting 06.06.2023

[Ivan Solovev via Development]

Hi Jani,

> 3 exception requests so far:
>  - C++20 comparison: exception request accepted
>  - container-assign epic: exception request rejected

I think it's the other way around - the container-assign epic is accepted, and 
the C++20 comparison is rejected.

Best regards,
Ivan




Ivan Solovev

Senior Software Engineer


The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany

ivan.solo...@qt.io

www.qt.io


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


From: Development  on behalf of Jani 
Heikkinen via Development 
Sent: Wednesday, June 7, 2023 7:20 AM
To: releas...@qt-project.org ; 
development@qt-project.org 
Subject: [Development] Meeting minutes from Qt Release Team meeting 06.06.2023


Qt 6.5 status

  *   Qt 6.5.2 preparations started
 *   First internal snapshot created and tested
 *   Target is to branch from ‘6.5’ to ‘6.5.2’ Wed 14th June
 *   Target is to release Qt 6.5.2 Wed 28th June

Qt 6.6 status

  *   Qt 6.6 Feature Freeze in effect now & branching from ‘dev’ to ‘6.6’ done
 *   3 exception requests so far:
*   C++20 comparison: exception request accepted
*   container-assign epic: exception request rejected
*   QMultiMap/Hash support in Qvariant: exception request rejected
  *   API change review started
 *   Most of diffs already available, see 
https://bugreports.qt.io/browse/QTBUG-114214
 *   Official review call will be sent to dev ML later this week
  *   Target is to release Qt 6.6 Beta1 immediately after dependency update 
round succeed in ‘6.6’



Next meeting Tue 13th June 16:00 CET



br,

Jani Heikkinen

Release Manager





irc log below

[17:00:13] <+jaheikki3> ablasche: akseli: carewolf_home: lars_:mapaaso: 
The-Compiler:thiago:vohi: ping

[17:00:23]  jaheikki3: pong

[17:00:24]  pong

[17:00:26]  pong

[17:00:35]  pong

[17:00:37]  jaheikki3: pong

[17:01:17] <+jaheikki3> time to start qt release team meeting

[17:01:23] <+jaheikki3> on agenda today:

[17:01:29] <+jaheikki3> Qt 6.5 status

[17:01:33] <+jaheikki3> Qt 6.6 status

[17:01:42] <+jaheikki3> Any additional item to the agenda?

[17:01:57]  Lets discuss the requested exceptions from Qt 6.6 feature 
freeze

[17:02:54]  (as part of the Qt 6.6 status)

[17:03:06] <+jaheikki3> vohi: Yes, agree

[17:03:19] <+jaheikki3> But let's start from Qt 6.5 status

[17:03:36] <+jaheikki3> Qt 6.5.2 preparations started

[17:03:54] <+jaheikki3> First snapshot created and tested

[17:04:13] <+jaheikki3> Target is to release Qt 6.5.2 Wed 28th June

[17:04:36] <+jaheikki3> So branching from '6.5' to '6.5.2' will happen Wed 14th 
June

[17:05:00] <+jaheikki3> that's all about Qt 6.5 status. Any comments or 
questions?

[17:06:27]  none

[17:06:48] <+jaheikki3> Ok, then Qt 6.6 status

[17:07:02] <+jaheikki3> Qt 6.6 Feature Freeze is in effect now

[17:07:13] <+jaheikki3> 3 Exception requests so far:

[17:07:33] <+jaheikki3> C++20 comparison, container-assign epic & 
QMultiMap/Hash support in Qvariant

[17:07:42] <+jaheikki3> vohi:

[17:08:01]  container-assign seems pretty clear cut.

[17:08:07]  greed

[17:08:09]  agreed

[17:09:28]  THe C++20 comparison less so, obviously. The discussion with 
Ivan has confirmed that this isn't needed for Qt 6.6, and given that the header 
review process has started, I don't quite see why we need to make an exception 
here. I respect that a lot of thought and work has gone into the implementation 
of course.

[17:11:21]  Since we won't make C++20 a requirement for Qt 6.6, and 
generally don't plan to make C++20 support on any level a part of the launch 
communication, I'm not quite seeing why we need to make an exception. The scope 
of what has been done is small, and I somewhat share Thiago's concern that 
maybe it's too small for us to see all the corner cases.

[17:13:14] <+jaheikki3> I understand and agree; we shouldn't make an exception 
for this because it isn't needed nesessarily for Qt 6.6

[17:14:03] <+jaheikki3> Any objections?

[17:14:27]  no

[17:14:32]  Alex is right in saying that we don't need to roll this out 
across all relevant types in all submodules, but a bit more than the two or 
three cases in Qt Core alone wouldn't hurt.

[17:15:36]  I think we need as a validation that it works

[17:15:53]  he has 5 types currently (the 4 date/time types and 
qfloat16)

[17:17:26] <+jaheikki3> It seems we agree no exception for the C++20 comparison

[17:17:44] <+jaheikki3> vohi: what about the last one (QMultiMap/Hash support 
in Qvariant)?

[17:18:17]  is there a timeframe mentioned?

[17:19:20]  no; Peppe doesn't know how to continue based on Thiago's 
input, so it's a bit open

[17:20:11]  We changed behavior, unintentionally perhaps, from Qt 5 to Qt 
6 by making QMultiMap no longer a QMap subclass (ditto QHash)

Re: [Development] Requesting Feature Freeze Exception for C++20 comparison

[Ivan Solovev via Development]

Hi Thiago,

Like I wrote, I generally consider this task done, except for the naming issues.
I have an impression that we will be able to come to an agreement in a 
reasonable time frame.

However, if you think that there are more issues, let's discuss them and see 
what we can do to fix them.
I totally agree that we shouldn't merge something that is not 100% ready.

Best regards,
Ivan




Ivan Solovev

Senior Software Engineer


The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany

ivan.solo...@qt.io<mailto:ivan.solo...@qt.io>

www.qt.io<https://www.qt.io>


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


From: Development  on behalf of Thiago 
Macieira 
Sent: Friday, June 2, 2023 4:47 PM
To: development@qt-project.org 
Subject: Re: [Development] Requesting Feature Freeze Exception for C++20 
comparison

On Friday, 2 June 2023 05:18:57 PDT Ivan Solovev via Development wrote:
> I'd like to request a Feature Freeze exception for the C++20 comparison
> task, due to the last-minute discussions about the names of the helper
> functions to be used. This is important because these helper functions are
> intended to be exposed as public API.

Is it important that we do this in 6.6? This API is likely to be very
important for us going forward, so why not take the time and ensure we've
caught all issues?

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

[Development] Requesting Feature Freeze Exception for C++20 comparison

[Ivan Solovev via Development]

Hi,

I'd like to request a Feature Freeze exception for the C++20 comparison task, 
due to the last-minute discussions about the names of the helper functions to 
be used. This is important because these helper functions are intended to be 
exposed as public API.

The task is https://bugreports.qt.io/browse/QTBUG-104113, which is a part of 
C++20 comparison epic: https://bugreports.qt.io/browse/QTBUG-103757

The relevant discussion happens in 
https://codereview.qt-project.org/c/qt/qtbase/+/475447, and the whole patch 
chain ends in https://codereview.qt-project.org/c/qt/qtbase/+/481410

Apart from the naming discussion, I consider the task to be almost done. At 
least most of the other comments are addressed at this point.

Best regards,
Ivan




Ivan Solovev

Senior Software Engineer


The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany

ivan.solo...@qt.io

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] Proposing changes to https://wiki.qt.io/Qt_Coding_Style

[Ivan Solovev via Development]

Hi!

+1 to all suggestions

Best regards,
Ivan


From: Development  on behalf of Marc Mutz 
via Development 
Sent: Tuesday, May 9, 2023 8:51 AM
To: qt-dev 
Subject: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style

Hi,

I'd like to propose the following clarifications:

- no space between "operator" and it's symbol:

 // WRONG
 bool operator ==()
 // CORRECT
 bool operator==()

Rationale: that's the style we find in all of Qt, but QtC's
auto-completion (by default?) adds the space, so we should clarify what
we want (and fix QtC).

- exactly one space each between if and constexpr/constinit and
following [({]:

// WRONG
if  constinit(
if constexpr(~~~) {
// CORRECT
if constinit {
if constexpr (~~~) {

- space after template and before <:

   // WRONG
   template
   // CORRECT:
   template 

Rationale: We always used the latter in Qt. Then a faulty _clang-format
that dropped the space for unknown reasons was added to qt5.git and
since then, we have a wild mix. We should fix the faulty _clang-format
file and codify just one variant in the normative document,
https://wiki.qt.io/Qt_Coding_Style.

- drop the requirement for () in lambdas

Rationale: this was a word-around for older MSVCs. The standard doesn't
require the empty parameter list (except when adorning the lambda with
noexcept etc, and then the compiler complains) and people have voted
with their feet: we now have many uses of [] {} in Qt already.

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

Re: [Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files

[Ivan Solovev via Development]

Hi,

+1 to the approach suggested by Kai.

Having comments would be very helpful, but I do not think that we need a 
separate comment field for each entry.

Best regards,
Ivan



From: Development  on behalf of Kai Köhne 
via Development 
Sent: Tuesday, February 14, 2023 4:07 PM
To: Edward Welbourne ; Development@qt-project.org 

Subject: Re: [Development] Support for *Notes and UpstreamFiles fields in 
qt_attributions.json files

Hi Eddy,

> -Original Message-
> From: Development  On Behalf Of
> Edward Welbourne via Development
> Sent: Tuesday, February 14, 2023 3:14 PM
> To: Development@qt-project.org
> Subject: [Development] Support for *Notes and UpstreamFiles fields in
> qt_attributions.json files
>
> Hi all,
>
> Having taken part in various third-party updates and felt a need to leave 
> notes
> for those who will do the same in future, I have run up against JSON not 
> having
> a comment format.  To work round that, I propose to allow some fields to be
> included in a qt_attribution.json file for that purpose.  As a general 
> pattern, I
> propose allowing ${Field}Notes for any ${FIELD} that already exists; and a
> separate UpstreamFiles field, corresponding to the Files one, to list where in
> the upstream source tree to find the files that are to be copied.

First, let's agree that JSON sucks for the task at hand. It doesn't have any 
explicit support for comments, and no support for multi-line strings (though 
our implementation tolerates this).

Anyhow, I wonder whether it wouldn't suffice to have _one_ comments field, 
instead of a dedicated UpstreamFiles field, and *Notes fields for every single 
entry. E.g.

{
  "Comments": [
 "Upstream files were copied from:",
 "   src/dir1, src/dir2",
 "The license and copyright was derived from dist/LICENSE.txt"
  ]
}

The benefit I see is that qtattributionsscanner (and any other JSON tool that 
might be used by others) has only to care about one additional field, not 
multiple ones.

Regards

Kai
--
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] New Qt example development guideline and revamping examples

[Ivan Solovev via Development]

Hi,

Should the example updates be picked to 6.5, or is it only a 6.6 thing?
Is there any general guideline from the Release Team?

Best regards,
Ivan

From: Development  on behalf of Kimmo 
Leppälä via Development 
Sent: Wednesday, January 18, 2023 10:51 AM
To: development@qt-project.org 
Subject: Re: [Development] New Qt example development guideline and revamping 
examples


Also, the guideline is a living document in wiki and we would be happy to hear 
feedback and proposals for it!



-Kimmo



From: Kimmo Leppälä 
Date: Wednesday, 18. January 2023 at 11.37
To: development@qt-project.org 
Subject: New Qt example development guideline and revamping examples

Hi,



We have started revamping Qt examples (https://doc.qt.io/qt-6/qtexamples.html) 
to follow the new example development guideline: 
https://wiki.qt.io/Qt6/Example-Guideline.

Target is to go through all the ~600 examples and either modify according the 
guideline or remove, if the example is obsolete or redundant and complete this 
activity by the end of June 2023.



Cheers,

Kimmo Leppälä


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: let's change the release schedules a bit

[Ivan Solovev via Development]

Hi Jani,

I'm not sure that I understand your proposal.
Currently we have FF on the 9th of December, and the release in March. So, it's 
roughly 3 months between FF and release.

Now you propose to shift FF to January (I assume, also around 10th ), and the 
release to April. That gives the same 3 months between FF and release.

Am I missing anything?

Also, as a developer, I personally find it good that we have FF before the 
holidays. Because having it right after the holidays would anyway mean that I 
need to have everything ready before the holidays. But I'll just have less time 
for that.
I can imagine that the Release Team has different opinion, though.

Best regards,
Ivan

From: Development  on behalf of Jani 
Heikkinen via Development 
Sent: Monday, December 5, 2022 12:40 PM
To: development@qt-project.org 
Subject: [Development] Proposal: let's change the release schedules a bit

Hi,

I am proposing a change to the our release "frame":

Currently we are releasing new Qt minor releases in March and in September. 
This is working quite well, but it is forcing us to have a Feature Freeze 
always before holidays and that's lengthening the calendar time needed between 
the feature freeze and the final release.

But if we would release minor releases in April and October, that would allow 
us to move FF also after the holidays: So FF for April release would be in 
January and FF for October release would be in August.

Any opinions or objections?

br,
Jani
___
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] Renaming quint128

[Ivan Solovev via Development]

Hi Thiago,

> Now at https://codereview.qt-project.org/c/qt/qtbase/+/444222

Thanks for sharing it!

> In fact, I came up with a better solution yesterday after sending this email:
move the support to QUuid. This allows us to have the new (mostly) source-
compatible API in place and simply move the existing QBluetoothUuid content to
removed_api.cpp.

This sounds like a good approach, but unfortunately it does not cover all 
usecases
for quint128 in QtBluetooth.
See, for example, struct SigningData in qlowenergycontroller_bluez_p.h
(https://code.qt.io/cgit/qt/qtconnectivity.git/tree/src/bluetooth/qlowenergycontroller_bluez_p.h#n152)
or class LeCmacCalculator 
(https://code.qt.io/cgit/qt/qtconnectivity.git/tree/src/bluetooth/lecmaccalculator_p.h#n23)
I'm not very familiar with the code but, AFAICT, these examples have nothing to 
do with QUuid.

However, they all are private, so we might just want to introduce a new private 
struct which will behave
similarly to the current "struct quint128", and that should fix the issues with 
private APIs.

> I'll wait for 6.6.

Good to know, thanks.

> https://codereview.qt-project.org/c/qt/qtbase/+/444237
https://codereview.qt-project.org/c/qt/qtbase/+/444238
https://codereview.qt-project.org/c/qt/qtbase/+/444239

I can only access the first patch. The other two links show "Not found".

Best regards,
Ivan


From: Development  on behalf of Thiago 
Macieira 
Sent: Friday, November 18, 2022 10:07 PM
To: development@qt-project.org 
Subject: Re: [Development] Renaming quint128

On Friday, 18 November 2022 09:05:51 PST Thiago Macieira wrote:
> In fact, I came up with a better solution yesterday after sending this
> email: move the support to QUuid. This allows us to have the new (mostly)
> source- compatible API in place and simply move the existing QBluetoothUuid
> content to removed_api.cpp.

https://codereview.qt-project.org/c/qt/qtbase/+/444237
https://codereview.qt-project.org/c/qt/qtbase/+/444238
https://codereview.qt-project.org/c/qt/qtbase/+/444239

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

Re: [Development] Renaming quint128

[Ivan Solovev via Development]

Hi Thiago,

> I was working on extended integers and added qint128 and quint128 to qglobal.h
(qtypes.h)

Can you provide a link to your WIP patch? I tried to search but couldn't find 
it in gerrit.

> it's used in the API, with a constructor and a toUInt128(), but that's
all. It's also not documented.

There are also many usages in the private API, plus some helper functions 
relying
on the fact that quint128 is a struct. So porting QtBluetooth to the new types 
might
require a bit more than fixing two methods.

> There's a way to replace it without breaking BC or SC:
1) on 64-bit systems with GCC and Clang, use the actual integer type
2) everywhere else, use the the struct
3) for QtBluetooth's own build, add a removed_api.cpp that also #undef
__SIZEOF_INT128__

This should work, but we need to make some experiments.
Are you planning to introduce q{u}int128 for 6.5 or for 6.6?

We are quite busy with other tasks before FF now, so I'm not sure
if we have time for that.

Best regards,
Ivan


From: Development  on behalf of Thiago 
Macieira 
Sent: Friday, November 18, 2022 3:13 AM
To: development@qt-project.org 
Subject: [Development] Renaming quint128

I was working on extended integers and added qint128 and quint128 to qglobal.h
(qtypes.h), but when I tried to rebuild all of Qt today, I found out that
QtBluetooth has this in qbluetoothuuid.h:

struct quint128
{
quint8 data[16];
};

And it's used in the API, with a constructor and a toUInt128(), but that's
all. It's also not documented.

I'd like to move it away so I can add the proper integer.

There's a way to replace it without breaking BC or SC:
1) on 64-bit systems with GCC and Clang, use the actual integer type
2) everywhere else, use the the struct
3) for QtBluetooth's own build, add a removed_api.cpp that also #undef
__SIZEOF_INT128__

It might be a good idea to move that backup definition to QtCore, so
QtBluetooth isn't depending on just how qtypes.h does it.
--
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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] How qAsConst and qExchange lead to qNN

[Ivan Solovev via Development]

> 1. It doesn't, obviously. If you emit signals, any signal argument must
>be owning, or QueuedConnection cannot be used. Given that C++20
>requires us to mark up views and non-owning ranges (enable_view,
>enable_borrowed_range), I'm confident that we could detect attempts
>to create such connections at compile- or, latest, at run-time, and
>refuse them, or, since we need to serialize the arguments into a
>QMetaCallEvent, anyway, also lifetime-pin, either by holding a weak
>reference to the source object or by storing the data in the event in
>an owning container.

I guess compile-time checks will be quite tricky, because we will need to check 
the threads
of both sender and receiver objects for the Qt::AutoConnection case.
Is it even possible at compile time?

As for the run-time check - I'm not a big fan of this approach either. It will 
be similar to the
metatype check that we have now (and which, I believe, is finally not needed 
with the latest
metatype changes). But I think that the code that compiles and runs, but then 
just refuses
to emit signals, is a potential source of errors and complaints.

> 3. Finally, the kinds of types I'm primarily thinking of in the context
>of NOI are not Q_OBJECTS. It remains to be seen in which form or
>shape co-routine-based reactive programming will complement or even
>substitute signal/slots in the future.

But then we will still have all the Widgets/ItemModels/Netwroking and much more 
around.
And those will still use Qt containers.
So, I would personally agree with what Volker has proposed in his answer:

> We need to come up with a naming convention for getters that returns 
> std::span so that we can add those APIs as alternatives.
> And perhaps we want symmetry between setters and getters working on spans, 
> rather than making std::span setters overloads.

Best regards,
Ivan

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] How qAsConst and qExchange lead to qNN

[Ivan Solovev via Development]

Hi Marc,

>> I would like to know how that is supposed to work in practice. We have a
>> lot of public API dealing with Qt containers all over. What are you
>> going to do to, for example, to
>>
>>  void addActions(const QList );
>>
>> in qwidget.h? What should it look like when we're done and our users are
>> free to choose the best container for their needs?
>
> In this particular case, the API would be
>
> void addActions(QSpan actions);
>
> This is the trivial case: setters for contiguous data. It's
> backwards-compatible, because QList implicitly converts to QSpan (and
> std::span), but now, as a user, I can also pass a C array or std::vector
> or QVLA of QAction*

I wonder how your NOI-everywhere suggestion will work with the signal/slot 
connections? Specially for the case when Qt::QueuedConnection is used 
(explicitly or implicitly).

Best regards,
Ivan

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development