Rust-style safety model for C++ 'rejected' as profiles take priority

Safe C++ proposal author claims that 'will not ever work'

The C++ standards committee abandoned a detailed proposal to create a rigorously safe subset of the language, according to the proposal's co-author, despite continuing anxiety about memory safety.

"The Rust safety model is unpopular with the committee. Further work on my end won't change that. Profiles won the argument

"The Safety and Security working group voted to prioritize Profiles over Safe C++. Ask the Profiles people for an update. Safe C++ is not being continued," Sean Baxter, author of the cutting-edge Circle C++ compiler, commented in June this year.

The topic came up as developers like Simone Bellavia noted the anniversary of the proposal and discovered a decision had been made on Safe C++.

One year ago, Baxter told The Reg that the project would enable C++ developers to get the memory safety of Rust, but without having to learn a new language. "Safe C++ prevents users from writing unsound code," he said. "This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety."

Safe C++ would enable incremental migration of code, since it only applies to code in the safe context. Existing unsafe code would run as before.

Even the matter of whether the proposal has been abandoned is not clear-cut. Erich Keane, C++ committee member and co-chair of the C++ Evolution Working Group (EWG), said that Baxter's proposal "got a vote of encouragement where roughly 1/2 (20/45) of the people encouraged Sean's paper, and 30/45 encouraged work on profiles (with 6 neutral)... Sean is completely welcome to continue the effort, and many in the committee would love to see him make further effort on standardizing it."

In response, Baxter said: "The Rust safety model is unpopular with the committee. Further work on my end won't change that. Profiles won the argument."

He added that the language evolution principles adopted by the EWG include the statement that "we should avoid requiring a safe or pure function annotation that has the semantics that a safe or pure function can only call other safe or pure functions." This, he said, is an "irreconcilable design disagreement. Safe function coloring is the core of the Rust safety model."

C++ inventor Bjarne Stroustrup advocates profiles, which, he told us, say: "I want this set of guarantees and it will then be enforced." According to Stroustrup, "the sad thing is, the standards committee got confused and did not guarantee that this would be in C++ 26."

That said, profiles are also controversial, with complaints, for example, that "profiles don't look like any established working solution, don't have an implementation, and also failed to get into the C++ 26 standard earlier this year, instead the committee wanted another whitepaper on it."

Baxter does not believe profiles will achieve the goal. "I would have implemented profiles if profiles had a chance of working. But they will not ever work. I present many examples of why they fail here: https://www.circle-lang.org/draft-profiles.html," he said yesterday on Hacker News. 

He added that "the whole Standard Library is unsafe. I proposed a rigorously safe std2, and that was rejected."

The controversy around how to make C++ safer may mean that turning to a different language is a better solution, whether that is Rust, or something else such as Google's experimental "successor to C++" Carbon project, whose roadmap states that it may ship a 1.0 language "beyond 2028." ®