C++ Committee Prioritizes 'Profiles' Over Rust-Style Safety Model Proposal (theregister.com)
(Sunday September 21, 2025 @11:34AM (EditorDavid)
from the language-barriers dept.)
Long-time Slashdot reader [1]robinsrowe shared [2]this report from the Register :
> 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 Safety and Security working group voted to prioritize [3]Profiles over Safe C++. Ask the Profiles people for an update. Safe C++ is not being continued," [4]Sean Baxter , author of the cutting-edge Circle C++ compiler, commented in June this year. The topic came up as developers like Simone Bellavia [5]noted the anniversary of the proposal and discovered a decision had been made on Safe C++.
>
> One year ago, Baxter [6]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 [7]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...."
[1] https://www.slashdot.org/~robinsrowe
[2] https://www.theregister.com/2025/09/16/safe_c_proposal_ditched/
[3] https://developers.slashdot.org/story/25/02/09/0636247/c-on-steroids-bjarne-stroustrup-presents-guideline-enforcing-profiles-for-resource-and-type-safety
[4] https://www.reddit.com/r/cpp/comments/1lhbqua/comment/mz3u7cr/
[5] https://sibellavia.lol/posts/2025/09/safe-c-proposal-is-not-being-continued/
[6] https://www.theregister.com/2024/09/16/safe_c_plusplus/
[7] https://isocpp.org/std/standing-documents/sd-10-language-evolution-principles
> 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 Safety and Security working group voted to prioritize [3]Profiles over Safe C++. Ask the Profiles people for an update. Safe C++ is not being continued," [4]Sean Baxter , author of the cutting-edge Circle C++ compiler, commented in June this year. The topic came up as developers like Simone Bellavia [5]noted the anniversary of the proposal and discovered a decision had been made on Safe C++.
>
> One year ago, Baxter [6]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 [7]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...."
[1] https://www.slashdot.org/~robinsrowe
[2] https://www.theregister.com/2025/09/16/safe_c_proposal_ditched/
[3] https://developers.slashdot.org/story/25/02/09/0636247/c-on-steroids-bjarne-stroustrup-presents-guideline-enforcing-profiles-for-resource-and-type-safety
[4] https://www.reddit.com/r/cpp/comments/1lhbqua/comment/mz3u7cr/
[5] https://sibellavia.lol/posts/2025/09/safe-c-proposal-is-not-being-continued/
[6] https://www.theregister.com/2024/09/16/safe_c_plusplus/
[7] https://isocpp.org/std/standing-documents/sd-10-language-evolution-principles