What I actually care about is code that intentionally serves C++ (with UCRT and Clang SIMD headers being typical examples), and as I have emphasized, some code that is entirely written in C++ also misuses static inline. I will not insist that libraries which do not like C++ should support C++; in that case, C++ users will need to do some extra work anyway.

From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Monday, June 22, 2026 21:14
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Andrey Semashev <andrey.semashev@gmail.com>
Subject: Re: [std-proposals] Proposal: Deprecate namespace-scope declarations that are declared both static and inline
 
On 22 Jun 2026 15:04, Yexuan Xiao via Std-Proposals wrote:
> 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?

I think that the argument from C library developers will be that the C++
modules problem is a C++ problem, not a C problem or their library
problem. And I would agree with their argument. There are libraries that
don't even bother adding `extern "C"` to their headers, I don't expect
them to make an extra effort to add a conditional compilation macro to
wrap `static`.

Bottom line is C compatibility is a very important use case for C++, so
C++ should remain as compatible with C as possible. If any C++ features
come into conflict with this compatibility, these features should adapt.

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals