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_at_[hidden]> on behalf of Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, June 22, 2026 21:14
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 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_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals