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:

The ability to enable/disable the feature in parts of the program.
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] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals