STINNER Victor <vstin...@redhat.com> added the comment:
>> 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". ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35059> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
