[Development] QVariant comparison in Qt6

[Lars Knoll]

> On 22 Sep 2020, at 08:54, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Monday, 21 September 2020 22:55:16 PDT Lars Knoll wrote:
>> I do not want to simply return an int, as the risk that people ignore the 
>> Unordered state it too big with that. So the other choice would be to add
>> an enum in the Qt namespace (as I need this for QMetaType as well, which
>> currently has a std::optional<int> compare()).
> 
> For internal APIs, please return just a plain int.

Those compare() methods are meant to be public.
> 
> For public ones, either call the internal or please use 
> std::optional<qsizetype>. Code generation is slightly better. Compare the 
> Clang panes at
> 
> qsizetype - https://gcc.godbolt.org/z/5bTbq6
> int - https://gcc.godbolt.org/z/b6jn8s

Really? Are we now making API decisions on how well a compiler manages to micro-optimize this? We have been using int as a return value for QString::compare(). qsizetype feels unnatural in this context, so I don’t want to use it.
> 
> The other three compilers just show how using std::optional is worse than an 
> int: both GCC and ICC currently unnecessarily spill to the stack (you can 
> avoid the spillage with std::optional<signed char>). MSVC always returns non-
> primitives by implicit reference, so a memory access is always present.
> 
> All the memory accesses go away if you call an internal function: 
> https://gcc.godbolt.org/z/rYde7c

Meaning you inline the public method.

Before we go to micro optimisations, let’s please first define what the best API would look like from a users perspective.

I can see three choices that don’t rely on C++20:

1)
std::optional<int> compare();

2)
enum class Ordering { Less = -1, Equal = 0, Greater = 1, Unordered = 0xff };
Ordering compare();

3)
Implement a Qt replacement for std::partial_ordering (could use the std stuff if C++ 20 is available) and use that.

Cheers,
Lars