> (Well-designed, first-class) GC is still the only system proven to completely remove memory safety issues.
This depends on what you mean by "proven", but I don't think I agree. It's pretty easy to demonstrate that RAII without raw pointers and without multithreading is going to be unable to escape its bounds. And for C++ that includes changing the standard library so it doesn't generate pointers without checking, for example vector is entirely capable of enforcing bounds.
But as you say, opting in on a per-object basis is not going to work.
I was saying "proven" more in the sense of "battle-tested": that is, we can point to large systems people actually use which are free of memory errors, written in Java or C# or other GC languages (those with a few more memory safety features, to be fair, such as out-of-bounds checks on all containers and a memory model that doesn't allow partial reads). We don't have a single large C++ system that is free of memory issues (we do have two for C, CompCert and seL4 - but those are not manually written in C, and they took many times more work than equivalent systems without this property). Perhaps some embedded high-safety systems such as embedded medical or avionics devices would qualify, but those are not public so it's hard to be sure.
So yes, theoretically you can build a complex system with a subset of C++ that is safe. Bjarne Stroustrup has explicitly defined such a subset for use in avionics and other military applications, even before many of the more modern C++ features. But there is little proof that this system can actually be successfully be deployed in most organizations.
I'd also note "without multi threading" is such a huge limitation that it immediately moves your proposed system to toy language territory in my book. And even adding shared memory multi-process collaboration (e.g. mmap() ) would not be safe.
Well not many languages are actually trying to hit the intersection of memory-safe but no-GC, so I think that's a bit too high of a bar.
> So yes, theoretically you can build a complex system with a subset of C++ that is safe. Bjarne Stroustrup has explicitly defined such a subset for use in avionics and other military applications, even before many of the more modern C++ features. But there is little proof that this system can actually be successfully be deployed in most organizations.
It's extremely difficult to deploy a subset of C++ as C++, for sure. I was thinking more about making a new specific language, but C++ could be a base for ease of explanation.
> I'd also note "without multi threading" is such a huge limitation that it immediately moves your proposed system to toy language territory in my book.
That's because I'm speaking about it as a proof of concept. Allowing multithreading is a hard problem, but it's not something that particularly shouts "you need garbage collection", so I leave it as an exercise to the reader.
Add some locks and stuff. There's a lot of ways to do it.
This depends on what you mean by "proven", but I don't think I agree. It's pretty easy to demonstrate that RAII without raw pointers and without multithreading is going to be unable to escape its bounds. And for C++ that includes changing the standard library so it doesn't generate pointers without checking, for example vector is entirely capable of enforcing bounds.
But as you say, opting in on a per-object basis is not going to work.