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.
On 14 Nov 2023, at 11:54, Edward Welbourne <edward.welbou...@qt.io> wrote:
Adding Qt::snake_case interims that are BC with std, with conversion
from/to QPartialOrdering, is the right thing to do.
Perhaps namespace q20 would be a better place for them, given both the
naming (snake-case, to match stl) and the plan ?
and
On 14 Nov 2023, at 12:01, Tor Arne Vestbø <tor.arne.ves...@qt.io> wrote:
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
We have so far not used any q20/23/xp APIs in public Qt API, and those
namespaces are not documented. The intention was for them to be used
internally, and the qNN headers contain the “not part of the Qt API” warning.
This doesn’t have to be set in stone, of course. Perhaps this is the exception
that confirms the rule.
OTOH, if the only reason for not using Qt::snake_case is because of the
snake_case, then it seems overly complicated to make that exception, or to
introduce a new namespace. It’s going to be part of practically every
value-type we have in Qt, which makes it a very very ubiquitous “exception”. We
have QList::push_back and QList::const_iterator for compatibility with the
standard. I don’t quite see why it would not be ok for Qt::*_ordering to exist
as a proper Qt names. The only difference here is that we don’t want to
introduce a Qt::CameCase equivalent, for the reasons given by Marc.
That they are short-lived as “independently defined entities” is an
implementation detail. Qt::*_ordering will work throughout the Qt 6 life-time,
also once they are just aliases to std::*_ordering; there won’t even be a real
reason to remove them for Qt 7.
On 14 Nov 2023, at 11:54, Edward Welbourne <edward.welbou...@qt.io> also wrote:
Speaking of q20, I notice its files live in corelib/global/; it occurs
to me that perhaps corelib/compat/ might be more natural (mainly because
it's the first place I looked for them). They are, after all, a piece
of compatibility machinery, albeit between Qt and C++ rather than
between Qt versions (as such - of course, the Qt versions' change of C++
standard does make them indirectly also between Qt versions).
Eddy.
module/compat is about backward compatibility with older Qt versions, and in
practice only includes the respective removed_api.cpp implementation file.
We include those qNN headers in public headers, and including something from
“compat” in public headers seems wrong.
Volker
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
