The naming makes sense, given their purpose. But can we put them in a dedicated 
Qt::std_compat namespace? Or is that too late? That would make it clear these 
are not Qt proper types (living in the Qt namespace), but dedicated compat 
types/BC/SC vehicles .

Tor Arne

On 14 Nov 2023, at 10:00, Volker Hilsheimer via Development 
<development@qt-project.org> wrote:



On 14 Nov 2023, at 09:40, Marc Mutz via Development 
<development@qt-project.org> wrote:

On 14.11.23 09:31, Marc Mutz via Development wrote:
[...]
And then naming them Qt::partial_ordering is just consequent, because
users can reach ultimate SC by doing something like

    #ifdef __cpp_lib_three_way_comparison
    using std::partial_ordering;
    ~~~~
    #else
    using Qt::partial_ordering;
    #endif

    ~~~ use unqualified partial_ordering ~~~

This will also mean that in Qt 7 we can maintain 100% SC with Qt 6 by
simply saying

  namespace Qt {
      using partial_ordering = std::partial_ordering;
      using weak_ordering = std::weak_ordering;
      using strong_ordering = std::strong_ordering;
  }

Done.


I agree with Marc here.

It’s tempting to add some Qt::Ordering::Partial, but it only makes things 
harder in the not-so-long run. From C++ 23 on, we can expect 
std::partial/weak/strong_ordering to become as ubiquitous as “true” and 
“false”. We should not invent our own.

Adding Qt::snake_case interims that are BC with std, with conversion from/to 
QPartialOrdering, is the right thing to do.

Volker

--
Development mailing list
Development@qt-project.org<mailto: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

Reply via email to