If we were creating a new modular language, it would be more straightforward. But the way I think about it is that we don’t want to change the existing language and, ideally, not pollute the code in a way that it becomes unfamiliar and also does not mix well with normal C++ code, so if you look at the code written in the “safe subset”, it would be indistinguishable. I think other than the compiler side of things, a critical part of such a solution actually being viable is a great tool, and GUI is a big part of that. This would enable us to enforce safety without changing the language itself at all.


> On Jun 4, 2025, at 6:10 AM, Thomas Krogh Lohse <tlohse20_at_[hidden]> wrote:
>
> > Of course, our understanding and suggestions are relatively high-level and abstract at this point. If an open-source version becomes available, we will have more valuable insights as we will be able to take a closer look and use it.
>
> At this point, I don't want to open-source the project, I really want to fix and touch up a few things. But hopefully I'll get to that in the summer, and also have a short and clear formal description of the analyses.
>
>
> > Ideally, both. As more types of analysis are added to such a solution, people would benefit from a more fine-grained set of checks. This way, one can, for example, turn on one check and refactor code, then proceed to the next check. This makes it more usable than trying to correct the results of many checks all at once, especially in a large codebase.
>
> Makes a lot of sense, I'll implement that as well when (if) I get the time.
>
> > Perhaps one option would be to have a “core” safe subset, let’s say the most strict set. Then, define “modules” that, when added, extend the core. Consider RISC-V, with its modular design, a “base” with “extensions.” While the base itself can implement a fully functional computer, extensions add additional features without conflicting with one another.
>
> Makes sense, wouldn't this require language extensions, unless there is a way to have language constructs as imported modules (or through pragmas)?
>
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Maryam via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Wednesday, June 4, 2025 12:18 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
>
> Of course, our understanding and suggestions are relatively high-level and abstract at this point. If an open-source version becomes available, we will have more valuable insights as we will be able to take a closer look and use it. Please see below:
>
>> > 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?
>
> Sounds sufficient for an MVP.
>
>> > 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?
>
> Ideally, both. As more types of analysis are added to such a solution, people would benefit from a more fine-grained set of checks. This way, one can, for example, turn on one check and refactor code, then proceed to the next check. This makes it more usable than trying to correct the results of many checks all at once, especially in a large codebase.
>
>> > 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.
>
> Perhaps one option would be to have a “core” safe subset, let’s say the most strict set. Then, define “modules” that, when added, extend the core. Consider RISC-V, with its modular design, a “base” with “extensions.” While the base itself can implement a fully functional computer, extensions add additional features without conflicting with one another.