I'm sorry, but Herb Sutter is too smart for his own good. He should not be involved in language design meant for mortals. I mean, who can honestly say both "For me, ISO C++ is the best tool in the world today to write the programs I want and need", but then also "I want to make C++ 10x simpler/safer/more toolable"?

As someone who dropped C++ almost entirely a decade ago because I couldn't deal with both the immense complexity and the legacy baggage of C++, this is pretty exciting honestly.

What I find a bit strange is that he explains that he's been working on this since 2015 (with "most of the 'syntax 2' design work in 2015-16") and he doesn't want to give documentation because "that would imply this project is intended for others to use — if it someday becomes ready for that, I'll post more docs."

Why this reticence to opening the project and have others play with it and, potentially, contribute to it? I can't imagine a new language becoming successful with this mindset.

"Fixing semantics" while keeping 100% ABI compatibility with old C++ seems really hard. It looks like this will have to allow for some kind of opt-in ABI breakage, at which point you're not far away from what you could achieve more easily by using e.g. Carbon, or just good Rust/C++ interop (see creusot).

Pros:

- Transpiling to C++ means it will work wherever C++ works. On any toolchain. With relatively little effort. It shouldn't be hard to add CMake and bazel support, for instance. Even mostly dumb makefiles should be workable.

- Approaching the community this way could avoid fracturing the community more than it already is.

- Targeting specific success metrics (like CVE causes) could provide focus around design and requirements

- Seems simpler and easier to learn and teach.

Cons:

- The pitch assumes C++ modules are implemented, ready to use, and reasonable accessible.

- There will be a lot of tooling to reinvent: static analyzers, syntax highlighters, etc.

- At least for a while, debugging cpp2 problems will involve juggling multiple parallel realities: cpp2 code, C++ code, and actual program behavior (i.e. compiled binaries).

- Doesn't address other major C++ ecosystem problems like build times, packaging, build systems, etc. cpp2 could make them slightly worse.

Seems like C++ is having an identity crisis lately

Looking forward to finding out what kind of feedback and discussion this generates. Some of the changes seem to make the syntax pointlessly different.

    /* Proposed "new" c++ syntax */
    main: () -> int = {
      cout << "hello world\n"; 
    }

    // vs.

    /* Classix c++ syntax */
    int main() {
        cout << "hello world\n";
    }

The "new" way looks a lot like a copy of the newer Java syntax for closures.

Carbonfront....

Compiler explorer supports cppfront https://godbolt.org/z/shYes883a

Seems more like a stupid panic reaction to Carbon. Both should be ritualistically burned. I recommend Byarnes recent talk: https://m.youtube.com/watch?v=2BuJjaGuInI

“main: () -> int = { hello("world\n"); }”

Kill it with fire.

> We've already been improving C++'s safety and ergonomics with every ISO C++ release, but they have been "10%" improvements. We haven't been able to do a "10x" improvement primarily because we have to keep 100% syntax backward compatibility.

You really don't. The vast majority of projects will never change the language version they use. Simple projects are simple to fix. Remaining large projects have enough resources and expertise to do changes across their entire code base - Chromium has recently changed more than 15000 instances (in over 8000 files) of using raw pointers to using raw_ptr instead in a single pull request [0]. How? They wrote a Clang based tool which did it automatically [1].

[0] https://chromium-review.googlesource.com/c/chromium/src/+/33...

[1] https://source.chromium.org/chromium/chromium/src/+/main:too...

This sounds very similar to how Jetbrains tried to improve on Java but in the end deciding to invent Kotlin; a new language with more consise syntax, better defaults, some new features, and great interop back and forth with Java.

Not a fan of making "import std;" on by default. I've already had enough headache where some obscure library or macro uses a name it shouldn't, I don't want to deal with even more of that. Plus, then it's inconsistent - everything else would properly state its namespace, but anything from std:: wouldn't.

The rest goes a bit over my head, but I'd be interested to see some of it in action/reviewed by other people.

> Can we make C++ 10x safer, simpler, and more toolable if C++ had an alternative "syntax #2," within which we could be completely free to improve semantics by applying 30 years' worth of C++ language experience without any backward source compatibility constraints?

Yes please - I really like this approach. C++ as a bare bones on-its-own language is not going to find adoption in the new world - it is way too much baggage & legacy, syntax and functional complications and adding more complexity every 3 years is just counter productive. If this can become something like what Scala or Kotlin are to Java it would be good for C++.

Man, the negative sentiment on this site towards C++ is pretty alien to me.

C++ is (I'm guessing) currently holding up an order of magnitude more applications than whatever you think is better than it. Clearly it has upsides, so it's baffling to me when people greet attempts to reduce the downsides with either "This doesn't make sense, just scrap it for something else" or endless nitpicks about the approach chosen.

A smart guy has decided to put his time towards improving a hugely influential language. That seems like an uncontroversial positive to me, and I welcome any useful results.

I find it disappointing that the enhancements aren't explained one by one, or even listed. How am I supposed to decide if it's worth a deep dive?

Drive-by, low-quality comment:

Herb is great. Glad he's thinking about this. C++ syntax is garbage and needs help, but why deviate so much from existing syntax? Why drop curly braces? The decision to allow mixing new/old C++ syntax in the same file seems like a gross mistake that prevents a more incremental fix of the language. Why the heck doesn't it support defining classes yet? Is it because of the aforementioned requirement to intermix new/old syntax?

I hope efforts like this continue, as we all know something is broken in C++ syntax. I think it can be fixed with tweaks and some breaking of backwards compatibility in the same source module.

I seriously wonder why no one did that before (put a context-free language in front of C++). Presumably, because of the need for modules to get anything beyond trivial code (without modules, one would have to use the preprocessor which would intermix old and new syntax).

Now, please do it. Context-free syntax is so obviously better that it's really an embarrassment, people are still defending hacks from decades ago.

And please, for the love of Knuth, someone do it with LaTeX, too.

I've written C++ and understand it's appeal: high level abstractions with very little runtime penalty, but I also understand it's legacy issues that make it complicated. Instead of adding to C++ maybe we should subtracting from it like perhaps C-- : The good parts of C++

teachers, leave our c++ alone!

In The Design and Evolution of C++ by Bjarne Stroustrup there is some interesting discussion on alternate declaration syntax that was rejected because it wasn't compatible with C. The book also explains a lot of design decisions that would be interesting to revisit in light of what has gone on.

Is that tiny, illegible-in-dark-mode hello world the only example or am I missing something? For as much content as there is in the README I would hope that a syntax change would, well, show some more syntax comparisons.

C++ was one of the first languages I learnt as an undergrad, maybe 20 years ago. I used it for a few hobby projects but not much else (professionally these days I mainly use Typescript & Go). I'd love to pick up C++ again but I've found it really challenging to discover what I should read up on to know what modern C++ should look like. What's a great resource for someone who's been out of C++ for a couple of decades to pick up and learn today's idiomatic C++? I don't want Rust btw - it's a great language but I want to revitalise my C++ knowledge, not jump ship entirely.

I've been engineering videogames in C++ for almost 20years working on AAA games and I can tell you that modern C++ is not very appealing to the vast majority of our industry. Modern C++ it's overcomplicated and from what I can see all the best software engineers I met in my careen write very simple C++98 code, maybe a bit of C++11 but that's it. They keep it simple. They don't need a move constructor because they've been already clever enough to solve a prolbem from a different angle. Modern C++ is for experienced C++ developers and it's solving problems that experienced developers know already how to solve without all this extra complexity. And because of that it's keeping away young developers... This new C++ syntax is just a gimmick that we don't need. The C++ community seems it's feeding itself to create a new standard every couple of years. It's just disappointing...

How is this called cpp2 and not C+++?

This is the best-engineered solution so far from a pragmatic point of view I have seen for C++ because it provides improvements with 100% compatibility.

Sorry for kind of x-posting (I posted in r/cpp the questions below), since I did not get any replies, but, Herb Sutter or anyone close enough, if you are around and have some time for questions... would love to hear more from this project.

I just saw the whole talk. Most ptomising C++ replacement so far for me: it is immediately useable and compatible and it does NOT duplicate standard lib and it is 100% compatible.

That said, here is my feedback/questions:

    About pass by copy. Dave Abrahams in his value semantics talk says copy is too eager in C++. Swift for example uses something sinilar to COW, avoiding eager copies when passing parameters. This also makes all copies de-facto noexcept. Is this the idea with Cpp2?

    About bounds checking: is it possible to call a non-bounds check function and detect it?

    About bounds checking: why always checked access? There are contexts, for example in a range for loop, where checks csn be ellided safely. Also, if you do checking in a span subspan, that slice traversal should not need checks.

    About bounds checking also: why the 3 subscript is a run-time error? I think it could be made a compile-time error for constants and constant folding.

    About overloading: one thing not mentioned in the talk. how are overload sets handled when you introduce the same name in the same context if parameter passing now is a bit different?

    About classes (no design yet, I know): there will be memeber functions vs free? How would overload resolution work? In case there are both memeber and non-member funcs, associated namespaces and so on. Also, it is interesting to look at Swift protocols and Val lang views here. Polymorphism comes from use, not from type itself.

    about exceptions: is it compatible to have lightweight exceptions and exceptions? my concerns here are two: should I annotate with try the calls and the result type of the function is affected (returning some ki d of outcome, reault, etc.). This is really viral compared to throwing from deep stacks and less usable as a default IMHO.

Sorry for the typos. Typing from a phone.

Each time (e.g., Rust, Go, Carbon, Cppfront, ...) before clicking, I hope that people would remember that Pascal pointer syntax is better than C's convoluted '*' and '->' and '.'. So far, I've been disappointed. I mean:

    'p.x'   just like 'p.x' in C, but
    'p^'    instead of '*p' and 
    'p^.x'  instead of 'p->x' and 
    'p^^.x' instead of '(*p)->x'.

Just admit it: Pascal is nice, clean, compositional, and less surprising.

Don't you remember? Or do you honestly think that C syntax is better?*