[The middle two quoted items did not appear in any version of my comment; my comment is very distant from the area of parsing.]

> Compilers can be made more simple

In relation to this issue, I do not see how. Today, someone can make a C++ compiler for a little endian system, or a retargettable one only for a group of little-endian systems, without any additional difficulty coming from the fact that C++ can also be implemented on big endian. Quite literally, that compiler developer need exert zero brain cycles even thinking about big endian.

C++ doesn't require implementors to have anything to do with big-endian.

A language standard that doesn't talk about endianness at all is smaller and simpler than one which specifies it, because that represents extra detail which generates extra requirements that require more sentences.

For C++ to "support" big-endian, all it has to do is not mention it: not give any requirements about it. That's not something that then needs to be dropped at any time.

A compiler project can drop big-endian; that's obviously different. ISO C++ isn't a compiler project, though.

The two middle quotes come from the article. They illustrate that the authors are interested in removing aspects of the language that contribute to tooling complexity.

The compilers that the authors care about are a small number of open source compilers that have very comprehensive support, and consequentially are very complex, probably just gcc and clang. With regard to this perspective, something like “lines of text in the standard” isn’t a useful metric. Few people are going to read the entire standard, so there’s little harm in making it longer, but many people are going to work on large compiler projects, and many, many people are going to use the compilers these projects produce. The standard can be made more complex in ways that reduce the required complexity of comprehensive optimizing compilers.

Numerous instances of wording in the article strongly suggest that the authors seem to be working under the confusion that ISO C++ is a compiler project, rather than a language specification.

> The compilers that the authors care about are a small number of open source compilers

If so, that is an unacceptable position for people on an ISO committee for that programming language.

> Numerous instances of wording in the article strongly suggest that the authors seem to be working under the confusion that ISO C++ is a compiler project, rather than a language specification.

There is no possibility that any of the authors are working under this confusion. The language specification heavily influences compiler projects because compiler authors tend to target standards. The argument that authors can just write their own non-standard compiler doesn't generally carry much water. Moreover it is extremely common for the standard to be written specifically to assist compiler authors. Consider the numerous instances of undefined or implementation defined behavior.

> If so, that is an unacceptable position for people on an ISO committee for that programming language.

The purpose of a standards committee is to standardize, not to standardize anything in particular. If the committee can be persuaded that these use cases are important to a large body of C++ programmers and that the alternative may be a split in the community, the committee may be inclined to adopt some of these topics as areas for improvement.

> not to standardize anything in particular.

Oh no, no. There is something particular to standardize: namely something that is already out there and working.

Secondly, if there are multiple such somethings that are out there and working, but are not compatible, then this is where the standard is really in its own element, to help iron out that situation and improve interoperability.

In this second area, the standard may engage in a bit of invention. Pure, unprompted invention is something ISO standards should eschew.