On Sun, Nov 27, 2022 at 12:12 PM Mehmet Kayaalp via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Let evolution runs its course freely
>
> James, Nadir, and Sebastian: Thank you for your comments and questions.
>
> Nadir, I believe we are on the same page—I have nothing to add/subtract to/from your comments.
>
> James, I believe you haven’t read my original posting—my apologies if I am mistaken and repeating myself unnecessarily: I believe C++ is on the right track by evolving itself over time. However, the ideal backward compatibility requirement as imposed hinders natural selection, which is at the core of evolution. As I said earlier: evolution involves not only the addition of new, worthy features to the gene pool but also the elimination of the old and nasty ones.
>
> Take a house metaphor. We continuously have been hoarding all new modern tools and storing them in this house, which has a limited capacity. The limitation here refers to our cognitive capacity. The bar you set for a “good” C++ programmer is raised every three years and, unfortunately, “the sky is the limit” does not apply to most mere mortals.
>
> Some people still do not believe that evolution is real because the changes are imperceptible to individuals. I do not believe changes in C++ from one standard to another should be too drastic; otherwise, the C++ community would be alienated. So, if the C++26 standard removes some archaic features in your hypothetical scenario, a codebase developed with C++23 standards would work very well with C++26 in all likely scenarios.

Would it, though? Who decides what "a codebase developed with C++23
standards" looks like?

One of the problems with this conversation is that everyone is talking
about extreme generalities in terms of what would be lost. You get
statements like "archaic features", which can be filled in with
anything the reader might want to put into that bucket. But what does
that actually mean on the ground?

Let's say you decide to put "C arrays" on the chopping block. OK,
so... how does `std::array` work? Like, internally? Does it now become
some kind of fundamental type, inherent to C++ rather than a wrapper
around a C array? How do you make arrays of runtime size without using
`vector`? Because that's still a thing people need to do. So you'd
have to add some functionality to cover those bases.

Indeed, I would say the biggest problem with throwing old stuff out is
that new C++ features are rarely comprehensive *enough* to completely
obsolete old ones.

List initialization in theory could have replaced every other form of
object initialization. But it didn't. Not because people just kept
using the old form, but because the new form was *incapable* of doing
everything the old one did. The most classic example being
`vector<int>` (where you cannot call the one or two integer
constructors with list initialization), but there are many others. And
thus, the supposed "uniform" initialization became a niche,
special-case tool. Just another form of initialization to learn on top
of the many others.

Also, some theoretically archaic idioms are not based on language
"features" per-se, but the interaction of different systems. Concepts
in theory makes SFINAE obsolete, but you cannot *outlaw* SFINAE
because it's a property of template instantiation rules. You can't
just take those out. Even if you could take out `std::enable_if`,
people can just roll their own compiler-specific versions (as they did
pre-C++11).

This "pie-in-the-sky" thinking is nice, but on the ground, removing
features often means removing actual functionality that someone relies
on.

> Sebastian, thank you for providing several options for me to choose from to make my position clearer; however, I do not have the temerity to suggest which features should be removed and which features should be preserved. Yet if you force me to do so, I would say the features that might go to the chopping block would be (1) those that are strongly discouraged from using and (2) those that make the life of a modern compiler designer horrible—I suspect your options C­ through F may be the closest ones to the criteria above.
>
> Best,
> --mehmet kayaalp