He's right though. Such a system would be slower than a good tracing GC, which completely eliminates these problems and is much easier for the programmer to use.
That sort of thing happens more than you know in CompSci. Example: One method for Oberon and Java appliances I pulled right out of an old Scheme CPU paper that was also impractical then. Also found a correct-by-construction HW method in same one. ;)
"supports the general thesis that garbage collection is neither necessary nor sufficient for quality software. This paper describes the techniques used to eliminate dangling pointers and to ensure resource safety."
"Every object on the free store (heap, dynamic store) must have exactly one owner [pointer/reference]"
"set the ownership bit when a value returned from new is assigned"
"use delete whenever a pointer with the ownership bit is set goes out of scope"
Sounds similar to what I read in Rust guide, esp one-per-location and scope part. Those and other rules appeared to make it easy for checks to prevent or catch use-after-free. If so, then my keep it around for hardware suggestion could lead to acceleration work. If I misread the paper or goals of ownership model, then my suggestion would've only led to accelerating... whatever safety it was trying to enforce.
Did that clear it up for you? Or did you spot where I went wrong? Could go either way given it was a quick read for me.
However, what made my jaw drop was section 3.2: "a dynamic model" for making the system safe and easily implemented in hardware. The section said Stroustrup deciced not to publish it because it was impractical. One of few times see his name and go "what an idiot..." What wasn't practical in general case or that time period doesn't mean it won't be in future in other circumstances. Good ideas, esp simple solutions, have a way of coming back to us.
Specifically, efforts like Cambridge's CHERI processor are looking at minimal modifications to CPU's to greatly increase assurance w/ legacy compatibility. This concept should've been published as there's use in embedded and appliance field where a lot uses subsets of C++. He should've published it. I'm saving the paper for my collection just in case that idea comes in handy.