3 ms·

You are describing the deficiencies of Rust implementation of a borrow checker and disregarding general benefits of it. Obviously there could be some way to mar

You are describing the deficiencies of Rust implementation of a borrow checker and disregarding general benefits of it. Obviously there could be some way to mark self-referencing objects. C/Zig do not even allow to specify who is responsible for freeing the allocation, and every time you use a library you need to either search the docs or (more often) reverse-engineer the code. Probably this is why writing or checking C code is so slow. I end up adding annotations to function prototypes but nobody is going to validate them so they only serve as documentation.

int_19h 2y ago
Well, we are comparing real world languages, so of course I'm going to talk about the limitations of the actual checker that Rust has. That said, is there a better (as in fewer false positives without giving up safety) implementation of lifetime tracking out there? I mean, fundamentally, the problem is that the question ultimately boils down to telling what the code will do without running it. C and Zig have exactly the same facility to let you specify who's responsible for allocation - owning vs non-owning types for resources; it's just that you have to write them by hand, and for types that are owning, destructor calls must be done explicitly (but still, the pattern of "if I got an instance of OwnedFoo, I need to call destroy() on it" is much more straightforward then chasing the docs for each function).