[felipefar]

They solve the use-after-free issue by keeping pointed objects alive, not by helping you think better about object lifetimes in your code. That means some objects will live for longer than you initially thought they would, and potentially even introduce circular references. Added to that, they also introduce random, unpredictable slowdowns in your application to run their algorithms.

I'm not yet sold on Rust, but exploring alternatives for achieving memory safety without needing to put on a GC is commendable.

[pizlonator]

> They solve the use-after-free issue by keeping pointed objects alive

That's not at all what Fil-C's garbage collector does.

If you free() an object in Fil-C, then the capability is marked free and the next GC cycle will:

- Delete the object.

- Repoint all capabilities that referred to that object to point to the free singleton capability instead.

This ensures that:

- Freeing an object really does free it, regardless of whether the GC sees it as reachable.

- Using an object after freeing it is guaranteed to trap with a Fil-C panic, and that panic is guaranteed to report that the object has been freed so you know why you're trapping.

Also, as a bonus, if you don't ever free your objects, then the Fil-C GC will delete them for you once they become unreachable. So, you can write Java-style code in C++, if you want.

> That means some objects will live for longer than you initially thought they would, and potentially even introduce circular references.

No idea what you mean there. Maybe you're thinking of reference counting, which isn't a form of garbage collection. (Reference counting is different precisely because it cannot handle cycles.)

> unpredictable slowdowns in your application to run their algorithms.

Fil-C's garbage collector is 100% concurrent. It'll never pause your shit.

[pornel]

Fil-C sounds very similar to Google's MiraclePtr.

However, Safe C++ (Circle) and Rust do much more than that. They are not limited to pointers on the heap, and the borrowing rules work for all references including the stack. They also work for references that need to be logically short even when the data is not freed, e.g. internal references to data protected by a mutex don't outlive unlocking of the mutex. And all of that is at zero runtime cost, and by guaranteeing the code correctly doesn't create dangling references in the first place, not merely by softening the blow of run-time failures of buggy code.