>> Py_STATIC_INLINE() is designed to replace a preprocessor macro with a 
>> function, when you care that the code is "always inlined". (Maybe the 
>> name is not perfect ;-))
>
> "always inline" is different from "static inline". So, it's not appropriate to make a macro named the latter that has the former former.

Oh ok. So if we decide to keep it, it should be renamed to Py_STATIC_ALMOST_ALWAYS_INLINE() or something like that :-)


> We don't want functions that behave like macros... otherwise, we would be writing macros. If we want a function to always be inlined, we should explicitly request that from the compiler.

Oh. It seems like I misunderstood you.

I understood that you required to have zero impact on performance on debug build.

*I* want to use functions because it's the regular C language: regular scope rules, no preprocessor magic, the compiler detects errors if the function is misused, etc.

But I'm not sure about the drawbacks of converting a macro to a function. I don't want to be the only one responsible to regressions :-) If you support the change, we can drop "__attribute__((always_inline))" and use "regular" "static inline" functions :-)


>> By the way, was it you who required "static inline" support in PEP 7? :-)
>
> Yes, which is why we shouldn't need a macro to write it.

Ok ok.

I updated my PR 10079 to simply use "static inline".