[Development] Deprecating Q_STATIC_ASSERT_X and Q_STATIC_ASSERT
Edward Welbourne
edward.welbourne at qt.io
Thu Jun 11 11:11:31 CEST 2020
Hi all,
On [0] there is discussion of deprecating these two macros, or even
outright removing them in Qt 6. I see the sense of deprecation, on dev
at least, since we expect C++17, in which static_assert() does the whole
job. Since they're macros, I know of no way to tell the compiler to
warn about their use, so the only deprecation we can do is in the
documentation - that doesn't yet exist; that's what [0] is seeking to
fix. So the deprecation would simply be a matter of marking them
\obsolete; in 5.15, we can mark the two-arg form as obsolete (since
static_assert(cond, msg) exists in C++11) but not the single-arg form.
[0] https://codereview.qt-project.org/c/qt/qtbase/+/303218
I also note that there's non-trivial #if-ery, still on dev, to support
compilers/platforms on which static_assert isn't available. I have to
suppose that is redundant, given that we expect a C++11 compiler in 5.15
and static_assert() is a compiler feature, not a standard library one
(where we allow some gaps on C++11, IIUC). So does anyone believe that
#if-ery is actually still needed - i.e. does anyone believe there is a
platform for which Q_COMPILER_STATIC_ASSERT *doesn't* get defined in
qcompilerdetection.h ?
Assuming there's no such platform, I propose to rip out (from both dev
and 5.15) Q_COMPILER_STATIC_ASSERT on the premise that it's always
defined and we can always use static_assert (or, in C, _Static_assert).
That then leaves the question of whether we deprecate in Qt 6 or remove
these macros. I shall leave Marc, who I understand as wanting the
latter option, to make the case for it, lest I misrepresent that case.
Are there any compelling reasons to just document these macros and
retain them, without marking as \obsolete in the docs ?
Eddy.
More information about the Development
mailing list