cppfront VS carbon-lang

I’m not fond of adding an increasing number of specific compiler options for memory-safety. I love -faddress=sanitizer or -fsanitize. But the historically growing number of warning which need to be turned on is an issue. For example the options -Wconversion, -Wsign-conversion and -Warith-conversion shall be default with C++26. And if your code doesn’t compile use either an older revision or turn it deliberately off (saying: I’m aware, read the handbook, I take the risk).

I want some of not all the ideas of CPP2/cppfront[1] in C++XX. Finally using #unsafe when needed, like Rust. C++ does evolve over decades, more like other languages.

[1] https://github.com/hsutter/cppfront

CPP2/cppfront:

https://github.com/hsutter/cppfront

I hope we see this in C++26 as optional mode i.e. #safe and #unsafe and same for #impdef or so.

C++23 is done. But C++ is not! In this talk, the author shares his personal perspectives on an ongoing and very active evolution of C++, updates on his cppfront experimental compiler, and why compatibility is essential to the further success of the C++ development.

https://github.com/hsutter/cppfront

But his side project at Microsoft didn't gain traction with gcc, clang, etc and everybody else in the industry. So at this point, the C++ committee will be perceived as "so far behind" ... because there's nothing for them to vote on.

C++ has major flaws that cannot be rectified without serious breaking changes. With that said, Herb has been experimenting with a new cpp frontend with sane defaults [1].

In my opinion, the world is on standby until Anders Hejlsberg feels like tackling a modern, next generation systems language.

[1] https://github.com/hsutter/cppfront

Thanks for clarifying that point. It's worth pointing out that the safety strategy doc[0] mentions that

>A key subset of safety categories Carbon should address are:

>[...]

>Data race safety protects against racing memory access: when a thread accesses (read or write) a memory location concurrently with a different writing thread and without synchronizing

But then later in the doc it says

>It's possible to modify the Rust model several ways in order to reduce the burden on C++ developers:

>Don't offer safety guarantees for data races, eliminating RefCell.

>[...]

>Overall, Carbon is making a compromise around safety in order to give a path for C++ to evolve. [...]

One could read this as saying that guaranteed safety against data races is not a goal. Perhaps this doc could be reworded? Maybe something like "Carbon does not see guaranteed safety against data races as strictly necessary to achieve its security goals but still we still currently aim for a model that will prevent them."

[0] https://github.com/carbon-language/carbon-lang/blob/trunk/do...

It's even a core point for Carbon, their hopeful C++ replacement

Under language goals on their readme,

> We also have explicit non-goals for Carbon, notably including:

> * A stable application binary interface (ABI) for the entire language and library

> * Perfect backwards or forwards compatibility

There's also this blurb

> Our goals are focused on migration from one version of Carbon to the next rather than compatibility between them. This is rooted in our experience with evolving software over time more generally and a live-at-head model. Any transition, whether based on backward compatibility or a migration plan, will require some manual intervention despite our best efforts, due to Hyrum's Law, and so we should acknowledge that upgrades require active migrations.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

The roadmap for Carbon [0] mentions wanting to have basic, non-trivial programs written in Carbon by the end of 2024. They're aiming for a v0.1 release in 2025. If it gains traction, they're aiming for a v1.0 beyond 2027.

I don't think anyone outside Google will seriously adopt this before it reaches v1.0. Even within Google, they may choose other options.

[0] - https://github.com/carbon-language/carbon-lang/blob/trunk/do...

Carbon was started by Chandler Carruth, at Google, but they wanted to move it to broader governance quickly. It's not under the Google GitHub today, but its own org.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

What do you think about Carbon[1]? I am hopeful.

[1] https://github.com/carbon-language/carbon-lang

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

next year 0.1 will be usable, 1.0 is about 3 years away, sigh, back to my rust fight