Hi,
Qt uses C++ feature test macros (__cpp_...) to detect post-C++11
features, and the status quo is that we only support compilers that
provide them.
This proposal does not intend to change this.
This proposal intends to change the de-facto status quo in how we check
these feature macros.
Currently, we check them for presence and their value:
#if defined(__cpp_foo) && __cpp_foo >= 201911L
// use foo feature
#endif
I have started to add these guard in tests without guards, so as to be
informed by CI when we encounter pre-standard values, which is one of
the reasons proponents of this style favour it in the first place.
While the version-less checks in tests are a very recent addition, I'd
recommend to deal with such special cases if and when they hit us, and
not earlier.
I therefore propose to allow the version check only when the code
thus protected actually depends on a non-initial version of the
feature.
Otherwise, a plain #ifdef __cpp_foo has to be used.
Rationale:
1. For the writer of the code, having to add the version check means
researching the history of a feature to unearth the value with which the
feature was originally added. cppreference.com is not very helpful in
that regard, as APIs are tagged with (since C++17), but not with (if
__cpp_foo >= 201911). There's a page listing all the values, incl., one
might hope, all the historical ones, but it's still extra work.
2. For the reader of the code, at least those poor souls who cannot
memorize all the feature macros' initial values, the version check
actively hides information: the structure of the code indicates that the
code depends on a certain version of the feature when in fact it
doesn't.
3. The wider C++ community seems to settle for non-versioned checks if
the initial version is sufficient, which may mean that Qt introduces an
impedance mismatch for pre-standard values where Qt checks the version
and users and other libraries do not. If there actually are non-standard
implementation who nonetheless defined the standard feature-test macro,
but with a lower value, Qt and the user will not agree on the presence
of a feature.
Flame away...
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
