> I'm not sure that `goto` should be on that list.
I actually discussed this in my Discussion chapter. I tend to agree, but also see some potential drawbacks, and suggest that it be removed, in place of some other constructs (for example labelled loops). But for current day C++, it should probably be in the subset.
________________________________
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> on behalf of Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, June 1, 2025 4:01 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jason McKesson <jmckesson_at_[hidden]>
Subject: Re: [std-proposals] Memory Safety in C++ via Safe Subset and Static Analysis - Master’s Thesis Summary

On Sun, Jun 1, 2025 at 4:32 AM Thomas Krogh Lohse via Std-Proposals
<std-proposals_at_[hidden]p.org> 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`

I'm not sure that `goto` should be on that list.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]p.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals