On 22 Jun 2026 14:23, Yexuan Xiao via Std-Proposals wrote:
> It seems that some C code likes to use static inline to indicate that a
> function should be inlined, but this is inconsistent with C++
> conventions. In C++, namespace-scope static inline is useless, and it
> also hinders the adoption of modules in two different aspects:
>
> When an external library declares a function as static inline, you
> cannot wrap that function as a module because functions with internal
> linkage cannot be declared as exported.
>
> When an external library declares a function as static inline, you
> cannot call that function from an exported inline function within your
> own module, because doing so would expose TU-local entities.
>
> I believe this is not an isolated case, because Windows' UCRT made this
> mistake, which blocked the STL for more than five years, and LLVM also
> made this mistake, causing many SIMD intrinsic functions to be
> unavailable. In my own experience, I have found that some Windows
> headers still have this problem, even though these headers only support
> C++, and the problem also exists in other codebases. Therefore, I
> propose deprecating namespace-scope declarations that are declared both
> static and inline, and encouraging compilers to issue warnings in older
> standard modes. This will help existing code migrate to modules. Any
> such issue can seriously block C++'s progress toward modularization. If
> the standard deprecates them and implementations issue appropriate
> warnings, they can be recognized more quickly and addressed individually.

If your proposal is to reduce compatibility with C (in which, as you
mention, static inline functions are quite common) then I'm opposed.
Between compatibility with C and C++ modules I'll pick C compatibility
every time. If modules can't be made compatible then drop modules.