> We of course continue to care that C++ supports all of the major, modern platforms, the hardware architectures they run on, and the environments in which their software runs. However, this only forms a fairly small and focused subset of the platforms that have historically been supported and motivated specific aspects of the C++ design. We would suggest this be narrowed as much as possible.
Well... take abandoning non-8-bit byte sizes. Are there any such architectures where someone was planning on shipping a C++23 compiler, but this would make it difficult or impossible? My impression is that for such platforms, you'd be lucky to get C++11.
Non-little-endian might be a bigger issue - it would rule out quite a few embedded CPUs.
If your code depends on endianness you're either over-optimizing or doing something wrong. At least that's what I've learned over may years of reading the lessons of many people.
If you're going to deploy your protocol buffer parsing library to literally a million servers you may be prepared to optimize the last shred of performance out of it. The authors have an unusual use case.
In embedded, you're often talking directly to hardware chips. How you talk to those hardware chips absolutely depends on the endian-ness of the CPU... unless the chips all have 8-bit-only interfaces.
If you're "over-optimizing" in a way that makes your code depend on platform endianness, you're definitely doing things wrong. Even then, it's quite possible to make compilation error out if targeting the wrong endianness. This isn't something that the C++ standard should be concerned with.
:(