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

[Marc Mutz]

Hi Thiago,

On 03.11.22 16:17, Thiago Macieira wrote:
> the devil will be in the details because of QT_REMOVED_SINCE.

What, specifically, are you thinking about here? For the sketched 
approach to work, no new relational operator must be exported, because 
we need to keep BC between C++17 and C++20 builds. If existing ones are, 
we'll need to QT_REMOVED_SINCE them. Where's the problem?

> For some classes, we could postpone changing anything until C++20 is required.

You lost me there. Why do you think so? Because of the sentence above? 
Requiring C++20 won't be a BC break, so we'd still have all the old 
exported relational operators to QT_REMOVED_SINCE.

> Meanwhile, we have qcompare.h.

Here, too, I feel lost. I'm struggling to see what a NIH 
std::partial_ordering w/o the weak and strong counterparts and w/o op<=> 
language support could achieve, except another vocabulary type mismatch. 
Can you elaborate?



Meanwhile, in a Jira comment, Eddy discovered a potential problem with 
partial_ordering::unordered: we have a lot of types that have 
std::optional folded into them (isNull/isValid) and, if they're ordered, 
they need to have decided on a total order, ie. incl. for invalid/null 
ones (QDateTime sorts invalid before valid e.g.). These types' op<=> 
could now return unordered for invalid values, but that would change the 
semantics of the op< derived from it vis a vis the existing op<.

I'm also fearful that Qt might be the only library that makes such 
widespread use of partial_ordering::unordered, because it's the only 
library that bakes optional semantics into so many of its types.

So, for new classes, by all means, use partial_ordering, but for 
existing types, I'd err on the side of caution and keep the total 
ordering for now and see how the greater C++ ecosystem's support for 
partial_ordering::unordered evolves. After all, unordered just means NaN 
semantics, and I've never heard of someone that likes that behaviour:

   NaN == NaN is false
   NaN != NaN is false
   NaN < NaN is false
   ...

Thanks,
Marc