On Tue, May 27, 2025 at 6:52 PM Maryam via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> I’d like to propose a slightly different perspective. In some fields, such as Embedded, people use C and C++ together often and hence rely on seamless compatibility as much as possible. switch is a C construct. Changing it in C++ can cause confusion but likely more serious issues. Generally speaking, if any C construct is to change, it is more appropriate for the proposal to go through WG 14 and be standardized in C first rather than doing it backwards.
>
> Honestly, I doubt WG 14 will approve such a change, so there is no point in pushing it as a C++ proposal.

While I understand that kind of thinking, I don't think it's
appropriate for cases where C++ is expanding a C construct. It's
already been done, after all; `for` was expanded into range-`for`.
`switch` itself was already expanded with an optional initializer
statement. C didn't get these changes, and C++ code written to use
them will not compile as C.

C compatibility really should only be a problem if C++ wants to make a
change that would prevent valid C code from compiling as C++. And that
wouldn't be the case here.