gh-99069: Consolidate checks for static_assert by jmroot · Pull Request #94766 · python/cpython (original) (raw)

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 :-)