> Speaking as someone interested in C++ interoperability with a particular focus on Rust, I think there could be a lot of value in a safe C++ subset similar to Rust's default mode.

My exact inspiration, and something I concluded in a previous semester project that C++ needs (not exact Rust, but similar).

> As for the analysis model, I'd need to learn more details about your approach, but I wonder how it compares to Sean Baxter's Circle work<https://safecpp.org/draft.html>. I know Sean was also highly influenced by Rust's implementation of borrow checking and my understanding is that one of the biggest hurdles is that it requires a new mid-level IR to do the necessary dataflow analysis.

I've read some of the the Safe C++ report, and I really like it, and respect it for the shear scope of it. But I do believe that this should be on by default, and that it is more than possible within current C++.
W.r.t. the new mid-level IR, I haven't had that issue, but that's most likely because of my small subset of the language.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jon Bauman via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, June 2, 2025 11:52 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jon Bauman <jonbauman_at_[hidden]>
Subject: Re: [std-proposals] Memory Safety in C++ via Safe Subset and Static Analysis - Master’s Thesis Summary

Hi Thomas, this sounds like really interesting work.

 I’d love to hear your thoughts:
    * Do you see value in defining a "safe-by-default" C++ subset with opt-in unsafe features?
    * Could something like this analysis model help enforce safety in future directions for the language?

Speaking as someone interested in C++ interoperability with a particular focus on Rust, I think there could be a lot of value in a safe C++ subset similar to Rust's default mode.

As for the analysis model, I'd need to learn more details about your approach, but I wonder how it compares to Sean Baxter's Circle work<https://safecpp.org/draft.html>. I know Sean was also highly influenced by Rust's implementation of borrow checking and my understanding is that one of the biggest hurdles is that it requires a new mid-level IR to do the necessary dataflow analysis.

On Mon, Jun 2, 2025 at 8:12 AM Thomas Krogh Lohse via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
> It is certainly promising and worthwhile. Good to see people are working on this important subject.

I agree, especially given the U.S. governments statements last year.

> The ability to enable/disable the feature in parts of the program.

Currently, I've added an attribute that allows developers to opt-out of the check, along with specifying functions and namespaces to omit through the commandline. Is there some better way to do this?

> The ability to include/exclude certain checks for a given run of the analyzer.

What do you mean exactly by that? Like, exclude use-after-move, but have the others? Or more broad, exclude the borrow checker, but have the lifetime?

> Good to have: It would be useful to be able to restrict the subset even more than the default “safe subset” by enabling specific criteria. For example, a feature, e.g., goto, could be controversial and not be excluded from the “safe subset,” but a user could exclude it in their own sub-"safe subset”. Or, it could be versioned, or, modularized.

I think this is a very nice and neat idea, though I have no idea how to (realistically) do this.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]<mailto:std-proposals-bounces_at_[hidden]>> on behalf of Maryam via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Sent: Monday, June 2, 2025 5:27 AM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: Maryam <maryam_at_[hidden]<mailto:maryam_at_[hidden]>>
Subject: Re: [std-proposals] Memory Safety in C++ via Safe Subset and Static Analysis - Master’s Thesis Summary

It is certainly promising and worthwhile. Good to see people are working on this important subject.

Having said that, users would want control, so a couple of must-have features would be:


  1. The ability to enable/disable the feature in parts of the program.
  2. The ability to include/exclude certain checks for a given run of the analyzer.

Without knowing how this actually works, it is hard to tell if this makes sense or is doable:

Good to have: It would be useful to be able to restrict the subset even more than the default “safe subset” by enabling specific criteria. For example, a feature, e.g., goto, could be controversial and not be excluded from the “safe subset,” but a user could exclude it in their own sub-"safe subset”. Or, it could be versioned, or, modularized.


On Jun 1, 2025, at 04:32, Thomas Krogh Lohse via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:

Dear all,

I’ve just submitted my master’s thesis in Software Engineering from Aalborg University (defending it on June 6), which focuses on memory safety in C++, and I’d like to briefly share the core idea of my project.

The project defines a conservative safe subset of C++, and applies two static dataflow analyses:
    * A lifetime analysis to detect use-after-free, use-after-move, and similar issues.
    * A borrow checker-style analysis to ensure mutually exclusive access to resources.

The safe subset is inspired by Rust and restricts some inherently unsafe constructs:
    * Pointer dereferencing
    * `new` / `delete`
    * `reinterpret_cast`, `const_cast`, and C-style casts
    * Union field access
    * Labels and `goto`

Instead, developers are encouraged (by the language) to use smart pointers for ownership and lvalue-references for borrowing, promoting RAII by default.

The analyses are implemented in a proof-of-concept Clang plugin. Users can annotate types and functions with attributes (e.g., to define smart pointer behavior or skip analysis — similar to Rust's unsafe). It’s still a prototype and has some scalability and precision limitations, but it successfully enforces the subset and detects key violations. The implementation uses Andersen’s pointer analysis.

Currently, the analysis does not handle polymorphism, exceptions, or lambdas, though I outline ideas for addressing these in future work.

If refined with a more precise pointer analysis, some over-approximation fixes, and extended support for more of C++, I believe this approach could provide safety guarantees similar to Rust — but within standard, modern C++, without requiring a new frontend or language changes.

I’d love to hear your thoughts:
    * Do you see value in defining a "safe-by-default" C++ subset with opt-in unsafe features?
    * Could something like this analysis model help enforce safety in future directions for the language?

I’ve tried to keep this short, but I’d be happy to elaborate on any part of the project if there's interest.

Best regards,
Thomas Lohse
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals