These threads usually focus on technical aspects of the language, while the non-technical ramifications of decisions are equally, if not more, important. What you are saying is technically correct. However, my point is about how people use them in practice. After all, we shouldn’t design for us but for millions of programmers out there unless we want only a few hundred people to use C++, leading to its demise. That’s not what we should want. That’s why safety, teachability and a clear API are extremely important.

It isn’t just C and C++. You can combine C and C++ and Objective-C and Objective-C++, and as a maintainer of such code, mentor, and manager of novice programmers, you’d want each language to stay cleanly in its own lane, and if they share a lane, they don’t crash into each other. Yes, we can explain to confused programmers, “This is a switch. In this C++ part of code, you can do this, but in this C part, you can not do the same thing, although they look similar.” That’s a waste of time. But we have a better option.

It is better if C++ creates new constructs, such as pattern matching, rather than changing those that came from C. Although technically correct and functional, an inconsistency creates confusion for novice programmers, and it is unnecessary.

As for other similar cases, I would be happier if they didn’t happen, although the case of ‘for’ is a bit different because range-based ‘for’ is syntactically different, which makes it clear this is something else, while the idea is ‘switch’ would have the same syntax but function differently which is confusing.

> On May 27, 2025, at 20:12, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals