I find the combination of 1) C++, 2) a goal of "Code that is simple and easy to read, understand, and write", and 3) a non-goal of backwards compatibility, to be strange.<p>The reason C++ is the federal tax code of programming languages is that it is the accumulation of decades of ideas that seemed good at the time--some even were--where each better way to program ended up as the lifeblood of some special interest group that can never be removed, only piled on top of.<p>By subsetting C++, you can customize it into almost anything you want with just a few exceptions. You can't meaningfully simplify it in a backwards compatible way without breaking most subsets.<p>So these people are saying it should be simplified in a non-BC way, the only real way to do it, that preserves their own favored subset.<p>That's what most of us call a new programming language. Trying to turn C++ into !C++ guarantees they'll be fighting over this for years. With the resources Google has, I don't understand why they don't just throw off all C++-based constraints and use those years to create exactly what they need. With half the PL PhDs on the planet in their employ, you'd think somebody would be available. (Maybe even enough for multiple, parallel teams req'd to share ideas with each other.) It would take a few years to mature enough to rely on, but they'd be spending those years in the C++ cmte debates anyway. A new language called "non-BC C++" will need new tools, new libs, etc., anyway, and they'll have the current C++ to keep using until their alternative is ready.<p>Why not just create that simple, easy, customized-for-server apps language from scratch instead of making it by breaking C++?
This proposal should read "Google's Goals and Priorities for C++", seeing as how almost half of the authors are from that company.<p>ABI stability? Backwards compatibility? Shipping binary code? The classic Unix compiler&linker model? Those are some of my favorite features of C++ over the competition. Just because GOOG chose to abandon them in their processes doesn't mean the rest of us should be forced to.
As a non-C++ programmer having to deal with C++ from time to time I don't really have a problem with the language (yes, it's huge, but there is no need to use everything) but with the tooling. Especially it's never clear to me how I should deal with dependencies and build systems, it's all different from project to project and often feel like a kludge coming from languages where setting up the environment is not much more than one or two commands. Even dealing with maven files and maven central repository felt easier than most C++ projects I had to work with.<p>In lieu of C++ we hear a lot about Rust these days, with focus on performance and reliability. But I suspect the rate of adoption is such because of the productivity aspect (it seems to me the language itself has non-trivial concepts and its fair share of syntax cruft from what I saw): having integrated tooling, dependency management, all being a de facto standard for the language. Same for Go, it's just very easy to start a project, add a library, compile a project... everything is included.<p>I guess it's probably not a priority for experienced C++ programmers as they are probably used to it, but I'm sure more people could build stuff in C++ without those barriers.
Fuchsia makes the list of OSes to prioritize but not *BSDs. This doc is biased toward the interests of Google. Which is Ok. They should just state that upfront rather than saying “our use cases” and leave it to the reader to figure it out.
Okay, humor me.<p>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.)<p>Will this be well-defined behavior?<p><pre><code> // Writing a 1 to u64 requires that u32 will read 1,
// because everything is little endian!
union u {
uint32_t u32;
uint64_t u64;
}
</code></pre>
Or, if not, what's the point?<p>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 <i>called</i> conforming any more?<p>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".<p>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.<p>What happened to the idea that systems require programming languages, not the other way around?
> 2. Non-goals<p>> 2.1. Stable language and library ABI<p>> 2.2. Backwards or forwards compatibility<p>> 2.3. Legacy compiled libraries without source code or ability to rebuild<p>For fucks sake, C has been stable for decades but somehow C++ just can't manage?<p>This is such an obnoxious attitude. At least let us automatically generate a set of C-style functions that take an opaque void* representing a C++ class instance if you can't be bothered to do the work.
Most of this I agree with. Frankly, though, Stroudtrup’s design goals are better: multi-paradigm programming, you don’t pay for what you don’t use, etc.<p>Some points:
* There are still tons of 32 bit machines out there—old Windows machines chugging along, usually disconnected (thankfully), and you’d like to be able to use your _current_ codebase to target them.<p>* If C++ is to focus on performance, it needs much better tooling around UB, be a bit more permissive of old behavior that now triggers UB, with formal semantics, AND it needs to define semi-portable SIMD vector operations. Getting the utmost performance out of modern CPUs entails using vector operations.<p>* It also makes me sad to say goodbye to big endian.
C++ needs to just steal the idea of Epochs from Rust
<a href="https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html" rel="nofollow">https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs...</a><p>By default, everything is backward compatible, but to use new features you need to declare this compilation unit as being part of C++23 (or 26, 29). Then code that uses the new stuff also ignores the old and can have different rules. But it can still be combined with legacy code and libraries. You know at compile and linking time when crossing boundaries and can do the right thing. This actually combines nicely with modules since we already need a new build infrastructure to take advantage of modules.
Interesting post. I'm bummed that there isn't more interest in bringing C++ to ASIC/Accelerator scene from the committee. I think projects like Nvidia's Thrust[1] show that C++ is poised to be fantastic medium for software developers to break into experimenting with FPGAs, GPUs, and potential future commercially available equivalents to the TPU. There is some really cool
cross-platform software infrastructure that is still under active development.<p>1 = <a href="https://thrust.github.io/" rel="nofollow">https://thrust.github.io/</a>
2 = <a href="https://mlir.llvm.org/" rel="nofollow">https://mlir.llvm.org/</a>
It's amusing to see the C++ committee finally taking safety seriously. I tried to get some interest in safety from there many years ago, but they were off into template la-la land back then.
Not to be negative but this reminds me of Python 3, where they want to make a largely but not completely compatible new C++. Like Python 3, it would be great to get a bunch of things fixed and force people to use the new, better, way of doing things. But, this comes with complications.<p>I am a C++ and Python developer. I did C++ for 20 years then python for 9, then C++14/17 for 3. I really like the new C++ and think it could be made into a better language while still retaining the deterministic performance.<p>What we don't want is Python 2 to Python 3 situation. That might mean calling it a new language.
> 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.<p>:(
It's clear these authors don't care much about the embedded community, which is too bad, since C++ is basically one of the two choices you have (the other being C). I prefer C on embedded (just because it's easy to accidentally allocate memory in C++), but there are large embedded ecosystems in C++ (Arduino, mbed).
<i>We believe that many divisive issues in the committee come from a disagreement on either stated or assumed priorities.</i><p>I’m curious: Which divisive issues would have had obvious resolutions if there had been broad consensus on the C++ committee to adhere to these goals & priorities?
From my perspective, people who wrote this have a lot of very good ideas and principles about software engineering.<p>But the impression it gives me is that C++ is not fulfilling the expressed requirements, and it is not currently moving in the right direction.<p>I read it as a quite strong critic of the current state of the language...
<a href="https://gist.github.com/fwsGonzo/6b12f502a3873725c17f44dc5e206c2e" rel="nofollow">https://gist.github.com/fwsGonzo/6b12f502a3873725c17f44dc5e2...</a><p>Very preliminary benchmark C++ Vs Rust on RISCV. C++ is just in its own league. Alone.<p>Having been at CppCon I can attest to the atmosphere of performance first in C++.
The first paragraph for the ABI non-goal section attacks a bunch of straw men about why a stable ABI is bad, then the second paragraph says they would actually be ok with doing what people actually want when they say they want a stable ABI.
I feel like you could make a near-C++ that could really get traction. Literally compile to C++ (and then compile from there) and just fix a ton of cruft in the language including:<p>- Stealing C# attribute notation instead of having the ridiculous __stdcall sort of convention<p>- Making a real fucking keyword for pure virtual functions instead of = 0<p>- A real keyword for include guards<p>- Function pointer syntax sugar<p>I now realize I'm describing D but D went too far. I just want like three nice changes that still allow near unchanged compilation to C++.