On Wed, Jul 2, 2025 at 5:03 PM Henning Meyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi David, thanks for your idea.
>
> What I want are C++ programs that are checked for correctness at build
> time instead of running into undefined behavior at run time.
> So there will be a static analyzer (using the compiler front-end and
> middle-end) that checks for pointer misuse, it does that by keeping
> track of which allocations come from new[], where do they go, and where
> do they end up (free/delete/delete[]/leaked).
> You cannot reason about correctness of C++ programs without tracking
> pointer provenance.
> The distinction between memory allocated by new and new[] really is a
> different type, and we have a very rich type system, that happens to
> have a blind spot when it comes to this difference. And everyone deals
> with that by layering complexity onto complexity.
>

In P3700 I try to categorize what work we already have and what we still
need for C++ to be a safe language. This is one of the areas that I
specifically call out.

We need to have the annotations and/or types to deal with knowledge of
"this is an owning pointer to an array type" for this to be a solveable
problem across TUs and in a global way. Some of the work in this area like
p0936 (lifetimebound) try to capture relations in attributes which may
work, but I don't think I've seen a paper yet proposing a way to
type-safely contain array-new.

Practically I would go for just subsetting out array new entirely... but
that could be complemented with a new type to wrap it safely that
type-safely transports it across. Doesn't unique_ptr have a specialization
that does this, and if so why not use it - if not why not add it there?


> Your suggestion represents the state of the art, which is everyone
> creates a custom wrapper that hides the ugly bits and creates custom
> guidelines to not use language features and use custom library types
> instead.
>
> I am fully aware that every change to basic types will break millions of
> lines of code, because there are billions of lines of C++ out there.
> There are also hundreds of little changes that would improve the core
> language, not just this one.
>

> If I want this change I probably have to go down the route of circle and
> cpp2 and fork the language (I won't, too much work).
>

Keep the language compatible, add to C++ what you need, and define profiles
that subset out what we want to prevent.