Comment by pizlonator

I think the point is that folks will incrementally move their code towards having all profiles enabled, and that's sort of fundamental if the goal is to give folks with C++ codebases an incremental path to safety. So I don't buy your first and second points.

> Which comes to the third part. Once you start down this path, as they found, you realise you actually want a borrowck.

That's a bold statement. It might be true for some very loose definition of "borrow checker". See the super simple static analysis that WebKit uses (that presentation is now linked in at least two places on this HN discussion, so I won't link it again).

> Your idea to do the reference counting everywhere is not something WG21 has looked at, I think the perf cost is sufficiently bad that they won't even glance at it. They're also not going to ship a GC.

The point isn't to have ref counting on every pointer at the language level, but rather: if your prevent folks from calling `delete` directly (as one of the profiles does) then you're effectively forcing folks to use smart pointers.

Reference counting that happens by smart pointers is something that they would ship. We know this because it's already happened.

I imagine this would really mean that some references are ref counted (if you use shared_ptr or similar) while other references use some other policy.

> Finally though, C++ is a concurrent language. It has a whole memory model which doesn't even make sense if you aren't thinking about concurrency. But to deliver concurrent memory safety without Fil-C's overheads you would want... well, Rust's Send and Sync traits

Yeah, this might be an area where they leave a hole. Like, you might have reference counting that is only partially thread safe:

- The refcount of any object is atomic.

- The smart pointer itself is racy. So, racing on pointers can pop the protections.

If they got that far, then that wouldn't be so bad. The marginal safety advantage of Rust would be very slim at that point.