On Fri, Oct 26, 2018, at 03:18, STINNER Victor wrote:
> 
> STINNER Victor <vstinner@redhat.com> added the comment:
> 
> Benjamin:
> > Why do we need this Py_STATIC_INLINE macro? If you want to have one for enabling always inline, that's fine with me, since it's compiler-specific.
> 
> For about the name, there is already Py_LOCAL_INLINE which also uses 
> "static inline", but has a very different usage: "Py_LOCAL can be used 
> instead of static to get the fastest possible calling convention for 
> functions that are local to a given module." So I chise 
> "Py_STATIC_INLINE" name, it describes the basic implementation ("static 
> inline TYPE").

I would like to see Py_LOCAL_INLINE removed, too, fwiw.

> 
> 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.

> 
> Honestly, I'm not sure that it really matters that the function is 
> "always" inlined. The main issue is that "static" requires to duplicate 
> the function in each file which uses the macro, when the function 
> cannot/is not inlined.
> 
> 
> Previously, you asked me:
> 
> > Does this slow down debug builds at all? It probably will not end will if Py_INCREF is ever not inlined.
> 
> That's why I wrote Py_STATIC_INLINE() to "force" inlining and PR 10094 
> to enable inlining for Debug build on MSVC.
> 
> 
> > But the current Py_STATIC_INLINE macro seems to conflate linkage with always-inline behavior.
> 
> I'm not sure that I get it. Do you talk about "static" inside the macro? 
> bpo-33407 modifies Py_DEPRECATED() to support Visual Stuido, but it 
> requires to modify how the macro is used: it now must be used at the 
> start, rather than at the end:
> https://github.com/python/cpython/pull/8980/files
> 
> I chose to put "static" and "inline" in the same macro. We already have 
> many other similar macros like PyAPI_FUNC(TYPE) and Py_LOCAL(TYPE). I 
> would like to have a common way to "declare a function behaving as a 
> macro".

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.

> 
> 
> Please see also the discussion on the PR itself, Neil discuss what's the 
> best way to declare an inline function:
> https://github.com/python/cpython/pull/10079#issuecomment-433230587
> 
> 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.