[Development] Deprecating Q_STATIC_ASSERT_X and Q_STATIC_ASSERT

[Lars Knoll]

We certainly shouldn’t start documenting the macros now in 5.15.1. 

IMO they should simply unconditionally expand to static_assert(). I’d also be ok if someone wants to do a search and replace s/Q_STATIC_ASSERT/static_assert/ in our source code. 

But I don’t think we should do much more right now. Adding a deprecation warning to the macros is something we probably can do sometime later in 6.x when people are not porting over from 5.15 anymore.

Cheers,
Lars

> On 11 Jun 2020, at 12:46, Marc Mutz via Development <development at qt-project.org> wrote:
> 
> Hi,
> 
> I don't care much about when we remove these macros, as it makes sense to keep using them in Qt 6 for code that will be backported to 5.
> 
> What I don't agree with is to go to extra lengths to deprecate (that would be cutting our own flesh, if we retain the macros for the above-mentioned use-case) or document-to-obsolete them. They weren't documented for 16 out of the 16 Qt 5 releases. Why then should we document the thing in 5.15.1? And, pretty please, decide NOW!
> 
> When and if we remove the Q_STATIC_ASSERT macros, there will hopefully be a [ChangeLog]. That's a much more fitting place for a macro deprecation/removal notice. We can reasonably expect people to read these. Who, otoh, would go to the API reference to look at macro definitions to see which ones are new \obsolete. That makes no sense.
> 
> Thanks,
> Marc
> 
> On 2020-06-11 11:11, Edward Welbourne wrote:
>> 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.
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development