Compilers can be made more simple, saving the time of expert compiler authors to work on improving their compilers in other ways. This lines up with some of the other listed goals,
> Syntax should parse with bounded, small look-ahead.
> No semantic or contextual information used when parsing.
i.e. drop features from the language that significantly complicate the compiler.
> What happened to the idea that systems require programming languages, not the other way around?
Hardware got very standardized and software got very expensive.
> 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 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.
> 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.
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.
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.
No, it’s illegal in C++. Use std::bit_cast.
What are you going to do if you declare that implementations must be little endian? (It seems that's where that particular goal is headed.)
Will this be well-defined behavior?
Or, if not, what's the point?What's the good in it, other than that: whereas a big endian machine can still have a C++ compiler, that compiler just can't be called conforming any more?
Nothing changes other than classification. Nonportable code depending on little endian continues not to work on that machine, though now that code might be blessed as "strictly conforming".
Someone wanting code to work on that machine will make it work the same way as before, and quite possibly keep their code strictly conforming. Like before, it will be possible to express code without endian dependencies, and that will work on those "broken" implementations that support big endian systems.
What happened to the idea that systems require programming languages, not the other way around?