[jlarocco]

I don't see what you're getting at with respect to writing bindings.

The whole point of using "static" in that way is to prevent people from using it outside of the file.

If you need to call a static function (inline or otherwise) from outside of the compilation unit to use the API, then it's a bug in the API, not a problem with static.

I agree with you about pre-processor macros, though.

[Mikhail_Edoshin]

Here is a use case. I have a function that takes variable parameters, so there is no formal type control:

    int Foo(int a, ...);

But in fact the types are restricted depending on a call type, set by 'a'. So I could add a wrapper for a specific variant:

    static inline FooVar1(char b, long c)
    {
        return Foo(FOO_VAR_1, b, c);
    }

All the wrapper does is adds a bit of type control during compilation, otherwise it must be just a function call to 'Foo'. It is like a supermacro. It does make sense to put that into 'static inline' in a header.

[1718627440]

Then what the FFI needs to target is `int Foo(int a, ...);`. FooVar1 is just a convenience method for the C language binding.

[yxhuvud]

Modern libraries consistently use `static inline`, to avoid the overhead of dynamic dispatch. Just take a look at liburing, and the client libraries for pipewire and wayland. All of them have `static inline` all over the place, for methods that are definitely intended to be called.

[zabzonk]

i think you replied to the wrong comment