On Sat, Nov 26, 2022 at 4:31 PM Mehmet Kayaalp via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Thiago, Sebastian, Bo, and Arthur: Thank you for your feedback and drilling questions. Based on your input, I revised the following sentence to disambiguate my intention (see the italicized parts):
> I fail to understand why we don’t come up with new preprocessor/compiler directives for each translation unit, indicating which compiler version should compile it to produce the intended assembler code (instead of compiling the entire set of codes with a single compiler).
>
> You all noted that this has already been done by others. But all mentioned solutions were outside of C++ standards; thus, they do not affect the decision-making of the C++ standardization committee. Without an intrinsic C++ solution that enables us to use the existing libraries and legacy codes, the C++ standardization committee would not attempt to eliminate the old baggage, simplify the language significantly and make the new C++ a more coherent language.
>
> > Why do we have to "eliminate" the old features? Just stop using them!
> The backward compatibility requirement (along with the long legacy of C and C++) makes the modern C++ language very complex, making it too difficult for newcomers to embrace and learn the language and master the language in its entirety. A simpler and more coherent new standard can be embraced by newcomers easily and would provide developers with explicit guidelines about the preferred features of the language. By ignoring this, we would be making C++ less and less popular in the coming decades.

Here's a question: what good are "newcomers" if their "mastering the
language" does not mean they've actually mastered *the language*?

I'm not talking about how a newcomer might be unable to work well in
C++17 through SFINAE if they're used to C++20 concepts. I'm talking
about how having basic elements of the grammar behave differently (and
therefore incompatibly) between versions is helpful to their
"mastery".

A good C++20 programmer should be able to at least read C++98/03 code.
They may not understand why the code does things a certain way, but
they should be able to understand what is happening. Archaic C++ is
still recognizable C++, even if it is primitive. What you want is to
effectively raise a generation of "C++" programmers who cannot even
read older versions of what is ostensibly the same language.

Furthermore, if you start gatekeeping language features behind
grammatical changes, what happens to people who want to use some of
those language features but *without* the grammatical changes? Like
they have a large codebase of C++23, and they want to use some
reflection from C++26. But your hypothetically incompatible C++26
means that they have to change a bunch of C++23 stuff that they have
no need to change.

With your suggestion, everything is either/or.

> We all can agree that such a new standard would not have all the bells and whistles of the current language, but with the proposed approach, one can always fall back on using the deprecated features supported by older standards for more flexibility and control.