[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