[RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

It is occasionally necessary to write a C header that uses atomic types then include it in a C++ file. For example, implementing an abi defined in C using C++.

This didn’t quite work out of the box - I think I needed to #include inside extern “C” or some similar absurdity - but I did get valid asm out of the result without modifying clang. Sadly I can’t currently access the source to check the details.

If this change goes ahead, would I no longer be able to use atomic types from a C header in C++?



With the implementation I have in mind, you won’t be able to use C atomic types from C++ by default. But you should be able to define a macro and use C atomics from C++. It will prevent you from using C++ atomics though. The idea is to prevent mixing and <stdatomic.h>, so only one of those should be included.

The plan is to allow to use C atomics from C++ but with minor hurdles so we’ll guide people towards preferred approach C++ atomics from C++.


That would be fine. The two languages expose roughly the same atomic capability so I would be able to ignore atomic and use stdatomic throughout.

It’s a bit sad to have the stable abi requirement ripple through the whole C++ library in the form of using the nastier API but I expect that can be wrapped. I should look into why can’t be such a wrapper.


+Marshall and Eric to get their thoughts from the perspective of libc++