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.