But in my example this is not hard to get right in C. The tree is constructed (on the stack would be fine), then used for a while without mutating it, then freed all at once.
The thing that makes this hard in rust is destructors. If there's a cycle between A and B, and you destruct A first, then B, then B's destructor would see a dangling reference to A. And vice versa if you destruct B first.
But I don't need destructors, or at least ones that can see these references, so it's frustrating.
For this purpose, no, I don't think. That said I might be missing something and maybe th compiler doesn't understand this, so I'm not saying it's a panacea in your case, just might be worth looking at.
The tree itself will need destructors to clean up allocations, and that's what's problematic here: if the tree is destroyed top down, the destructor of the children may access the parent which has already been invalidated, and similarly destroying bottom up risks the destructor of the parent accessing the children.
> But in my example this is not hard to get right in C. The tree is constructed (on the stack would be fine), then used for a while without mutating it, then freed all at once.
It's still "hard to get right" in that at any time nothing is stopping you from violating any of the assumptions that make this "easy". It's never easy to write a solution that's "guaranteed to be safe" in C, but that's what you're trying to do by writing such a solution in Rust. To give but one example, nothing in C will stop your nodes from containing some resources which needs to be manually destructed and which get leaked when the stack frame is reclaimed.
Rust is going to require you to make those assumptions explicit, so that it can enforce them -- in this case, you need to explicitly restrict your solution to dealing with Copy types, which by construction don't implement Drop, and therefore have no destructors.
But at the end of the day, if all you want to do is swear to the compiler that you know what you're doing and you promise to not be stupid, wrap it in an unsafe and get C-style consequences if you got things wrong. You get C-Style easiness only by explicitly abandoning the attempt at guaranteeing safety for every type and scenario your solution could be used with.
Nothing stops you from leaking memory in Rust either, it is considered memory safe, see std::mem::forget. Rust only safes you from use-after-free and double-free.
The thing that makes this hard in rust is destructors. If there's a cycle between A and B, and you destruct A first, then B, then B's destructor would see a dangling reference to A. And vice versa if you destruct B first.
But I don't need destructors, or at least ones that can see these references, so it's frustrating.
reply