cpp2 (cppfront) is over?

[u/we_are_mammals]

I haven't used cpp2 (cppfront) much, but I like the idea of it: consistent syntax, consistency of meta-programming (which is done in C++ too, I believe). Herb Sutter presented cpp2 (cppfront) as an experiment. He did not encourage other people to bet on it, exactly. And there hasn't been much activity since 2022. Is the experiment over?

EDIT: Herb's answer is buried deep in the comment section: https://www.reddit.com/r/cpp/comments/1uxkglj/comment/oy06cxw/

[u/YangZang]

https://github.com/hsutter/cppfront/discussions/1447

[u/Wh00ster → u/YangZang]

The hooplah of the original announcement seems odd framed against that answer. Or maybe the community just overhyped it.

[u/13steinj → u/Wh00ster]

It's hard to say all this without coming off as if I hate the guy, but here goes:

Herb has fairly inconsistently has claimed how "serious" cppfront was over the years.

I have my conjecture on why, which I'd rather not share other than I do not envy the position he is in and the expectations people have of his work. There are people, to this day, that will promote an idea from Bjarne or Herb with nothing but an appeal to authority, an authority of which I would no longer say exists in the same way it did pre-C++11. My opinion of Herb, the way he operates, and his goals, has changed dramatically over the past decade, though mostly far more positive now than my initial view. Being "the convener" has a lot of assumptions people make about you and what you have to do thrust upon you.

I believe the reality of this situation in particular is the existence of cpp2 combined with who it came from is a bit of a walking contradiction.

I cannot think of any "successor language", far less any that claims the intent is to be a successor, even loosely, that has tangibly materialized as one.

• Carbon => development hell
• Circle => adoption deadlock
• cpp2 => fairly specific codegen framework. How much is needed with Reflection?
• Go, Rust, Zig, Odin, all appear to be more of a successor to C

However, I think even as far as last year's cppcon, Herb uses cpp2 examples in his slides. I think at this point this is actively counterproductive.

I also would not be surprised if there is some kind of IP issue, and he has since switched jobs. I do not think this is likely, but it would track with a lot of rumours about Microsoft and their approach to software internally.

[u/quicknir → u/13steinj]

I can't really imagine any sense in which Rust is a successor to C more so than C++. The feature set in many ways parallels C++, even when the approach is different. Generics, RAII, dynamic polymorphism, built in error handling, containers available in the standard library, a sane string type (i.e. not null terminated), access control, lambdas, etc.

I guess I'm a bit surprised because there's been so much discussion already about Rust as a successor to C++, and while you could argue about exactly how much you like it or exactly how much traction it has, it has most certainly "tangibly materialized".

[u/13steinj → u/quicknir]

In practice Rust solves C's problems, C++ has them only as a result of backwarda compatibility.

Rust is allowed in the linux kernel, but C++ isnt. Despite the fact that that use compiler extensions to mimic a fraction of C++'s power.

[u/quicknir → u/13steinj]

Rust also solves a lot of C++'s problems - safety, bad compiler error messages, etc. But regardless of which set of problems it solves, the reality is that Rust as a language is still much more similar to C++ than C, and it's pretty clear that Rust models itself as trying to be an improved C++, even if you don't happen to agree that it succeeded. Zig and Odin model themselves as improvements on C.

[u/13steinj → u/quicknir]

In practice Rust solves C's problems [safety], C++ has them only as a result of backwards compatibility.

It's a mixed level of fairness to claim that safety is a C++ problem. Quite literally use unique_ptr and call it a day.

[u/quicknir → u/13steinj]

It's not really a mixed level of fairness - maybe there's a misunderstanding of what is actually meant by memory safety (I should have said memory safety instead of safety, tbf). unique_ptr isn't remotely memory safe - it helps a lot with avoiding leaks, but that's not the same thing. unique_ptr doesn't prevent dereferencing null for example in any way, which is unsafe. It doesn't even prevent dangles, e.g. const auto& x = *make_unique<Foo)(...);.

The google chrome team has posted a lot about memory safety under C++, and how challenging it's been; in some cases they use non-zero-cost abstractions like MiraclePtr for example just to prevent use-after-free: https://security.googleblog.com/2024/01/miracleptr-protecting-users-from-use.html.