[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