https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122667
--- Comment #3 from Marc Mutz <marc.mutz at hotmail dot com> --- > You can also get the same effect with: > [...] > But I don't see any reason for a special pragma here really :). I mentioned this option in the original report, and why I don't think it's an adequate replacement: > [...].Fallbacks like injecting a deprecated function call into the macro > expansion > don't always work (cf. ATOMIC_VAR_INIT) and when they do, they're > user-unfriendly, > because the compiler is complaining about a function that's invisible in the > source. Another problem with that approach is that, potentially, in debug builds, the function actually gets called, unless you force constant evaluation by marking your std::atomic's as constinit. Imagine turning an atomic static initialization suddenly into dynamic initialization that participates in SIOF (because the comma operator forces the evaluation of the function to be sequenced before the production of the initial value and, therefore, the init of the variable). That said, we have used this mechanism in the past: https://codereview.qt-project.org/c/qt/qtbase/+/147363/3/src/corelib/global/qglobal.h In Qt, we will very likely start using Clang's pragma to deprecate some of our old macros (cf. https://codereview.qt-project.org/c/qt/qtbase/+/690963). There are certainly more where these come from, including some that are only for configuration purposes, like It would be nice if GCC would be able to show these, too, but for the purposes of a cross-platform project, it suffices, of course, if only one common platform shows them. Incidentally, the two macros from the Qt commit don't work with the inject-deprecated-function-call-into-macro-expansion, because they're used at the class level, and, even though deprecated, you don't want to inject into your public API member functions in the body of which you could call the deprecation marker function.
