GeezerVison

@vstinner Is there something that is defined iff Python itself is being built? Other users of the headers don't necessarily need static_assert, so it would be nice to avoid defining it as an unexpected side effect. I guess that would allow removing the __cplusplus checks too, since Python won't be built as C++?

Sadly, static_assert() is now part of the Python 3.11 C API. Removing it from its public C API in a 3.11.x bugfix release would be worse IMO.

In practice, which platform/libc/compiler is impacted by this change? It would be nice to add a NEWS entry to discuss which platforms are affected.

cc @pablogsal who modified this macro recently.

cc @ambv who may have an opinion on the macOS 10.10 support (issue #99069), purpose of this PR if I got it correctly

In practice, which platform/libc/compiler is impacted by this change?

I only know of the ones mentioned in the comment, i.e. FreeBSD <= 12, macOS <= 10.10, and glibc < 2.16.

I was very excited to be able to get rid of Py_BUILD_ASSERT() "hack" with a well defined (!) static_assert() function of the C11 standard. But month after month, I see that: weeeeeell, it depends, maybe it's available, maybe not. It depends on the libc, on the compiler, on the OS, etc.

Maybe we should give up with static_assert() and use _Static_assert(). Coming from Python, for me it's weird to use a name starting with an underscore :-( It reminds me non-standard APIs on Windows which looks like POSIX but are different, like _open().

Maybe Py_BUILD_ASSERT() is just better since it's battle tested (in Python) and it "just works" :-) I didn't expect that it would be so complicated to get static_assert() on all compilers on all platforms in 2022 :-(

A tradeoff might be to only use static_assert() inside Python and remove it from the public Python C API. Then the funny part is that depending if the proper (hypothetical) Python internal header file is included or not, using static_assert() might work or not. The problem is that some Python macros use assert(), so Python.h includes <assert.h>. But as you can see, static_assert() may or may not be available, Python currently has a complicated macro to make sure that it's always present. What if an internal Python C file uses <Python.h> but forgets to include "pycore_assert.h"? Maybe it works on all platforms. Maybe it fails on some specific platforms. Fun. Isn't it? That's why I put it in the public C API.

"Well defined": people are now discussing static_assert() with a single argument. I'm curious when it will be standard and when all compilers on all platforms will support it :-)

@vstinner @pablogsal Is there a consensus for how you want to proceed here?

@pablogsal asked to add __has_feature(c_static_assert) check. I don't see this check in your PR yet. Does it mean that you are against using it, and if yes, why?

@vstinner Sorry if I misinterpreted your comments above; it looked to me like you were disagreeing with @pablogsal's proposal.

My own view is that a clang-specific check is not necessary, because the existence of _Static_assert does not depend on the stdlib at all, and all versions of clang that accept -std=c11 or -std=c1x provide that keyword. Restricting the define to clang and gcc would be reasonable though, just in case other compilers do something weird.

@pablogsal Is this acceptable now?

Yup, this looks good to me. Thanks for working on this!

@vstinner What is still needed for this to be ready to merge?

Thanks @jmroot for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

GH-103282 is a backport of this pull request to the 3.11 branch.

Merged, thanks.