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]> 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]> on behalf
> of Maryam via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Monday, June 2, 2025 5:27 AM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Maryam <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]> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>