Your statement doesn't solve any problem. For users of modules, they either have to abandon this library or seek improvements from it. Basically, these C libraries only need to stop using static when the __cplusplus macro is defined, and that would solve the issue. There's no need to abandon C++ users, nor do C++ users need to abandon them. Why do you assume that these C libraries will never be improved?
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, June 22, 2026 19:52
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Andrey Semashev <andrey.semashev_at_[hidden]>
Subject: Re: [std-proposals] Proposal: Deprecate namespace-scope declarations that are declared both static and inline

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.

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals