[libcxx-commits] [PATCH] D115995: [libcxx] Add deprecation notices to macros deprecated in P0883R2

[Raul Tambre via Phabricator via libcxx-commits]

tambre added a comment.

In D115995#3205826 <https://reviews.llvm.org/D115995#3205826>, @Quuxplusone wrote:

> In D115995#3205377 <https://reviews.llvm.org/D115995#3205377>, @tambre wrote:
>
>> In D115995#3205319 <https://reviews.llvm.org/D115995#3205319>, @Quuxplusone wrote:
>>
>>> 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
>>
>> I don't see why you'd think using the macro would be required.
>
> AFAICT, on paper, C++17/20 `atomic_flag` has no constructors
> https://en.cppreference.com/w/cpp/atomic/atomic_flag/atomic_flag
> except for the default constructor (trivial in C++17) and the deleted copy constructor. So if you want an `atomic_flag` initialized with `false`, you need //some// way of getting `false` into it. On paper, there's no guarantee that `std::atomic_flag f = {false};` will compile. But I just checked Godbolt and every major compiler //does// support that syntax, so I suppose it's safe to use in practice: https://godbolt.org/z/4cbbGcv96

Ouch, you're correct. I was looking at `std::atomic`' not `std::atomic_flag`. Does seem like an oversight.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115995/new/

https://reviews.llvm.org/D115995