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@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@qt-project.org >> https://lists.qt-project.org/listinfo/development > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
