[libcxx-commits] [PATCH] D115995: [libcxx] Add deprecation notices to macros deprecated in P0883R2
Arthur O'Dwyer via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Dec 21 11:25:02 PST 2021
Quuxplusone added a comment.
Okay, now that I'm hitting this in a real codebase, I'm stumped as to what the (WG21 and/or libc++) recommendation is, here. `ATOMIC_FLAG_INIT` is //required// up-to-and-including C++17, and then //deprecated// in-and-above C++20? So if I have code in my codebase today like
std::atomic_flag flag_ = ATOMIC_FLAG_INIT;
should I change it to
std::atomic_flag flag_ = {false};
or
std::atomic_flag flag_;
or what? How am I supposed to eliminate the deprecation warning? I've thought of
- stop allowing my codebase to compile in C++17 mode; require C++20 (this is a non-starter)
- write my //own// macro using `#if __cplusplus >= 201700L`
- turn on `-Wno-deprecated` in the build system
- just use `= {false};` or `;` on the assumption that I can file bugs against any library vendor that I catch doing the Wrong Thing in C++17 mode (but then I'd have to fall back to one of the other options anyway)
None of these options feel very nice.
This is the same situation we had with `random_shuffle` in C++11: https://stackoverflow.com/questions/27791474/what-are-best-practices-for-simple-random-shuffling-in-code-thats-both-c03-an
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D115995/new/
https://reviews.llvm.org/D115995
More information about the libcxx-commits
mailing list