Benjamin Peterson <benja...@python.org> added the comment:
On Fri, Oct 26, 2018, at 03:18, STINNER Victor wrote: > > STINNER Victor <vstin...@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. ---------- _______________________________________ 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