> Want to catch that where the Rc is dropped, not at .upgrade time(). And maybe at compile time eventually.
Catching that at compile time will require something that looks more like a reference into the `Rc` than a `Weak`. Most likely not the ergonomics that you want.
Catching at runtime is IMO not much different than panicking on the field access and IMO it's not enough.
> This is checkable at run time
Not sure how you check that a panic cannot occur at runtime without panicking in the first place...
> It's very similar to finding double-lock mutex deadlocks, though.
I'm not sure how they are similar. Last time I checked mutexes still required an explicit `.lock()` to be locked.
> Problems of this class are all of the form "this thing here conflicts with that thing way over there", and users need to know both ends of the conflict. The Rust borrow checker is good about that.
The last sentence doesn't make sense. You wanted to use `Rc`, `Weak` and `RefCell` precisely to avoid the kind of restrictions that are needed for the borrow checker to perform its analysis. Either you keep those restrictions and you have reference semantics or you discard them and are forced to perform runtime checks. There's no free lunch.
Your arguments basically boil down to hypothetical compile time check that doesn't exist or to arguing that hidden runtime checks are fine because you can test the code in debug mode to hopefully catch them failing. Neither of them are convincing enough.
Catching that at compile time will require something that looks more like a reference into the `Rc` than a `Weak`. Most likely not the ergonomics that you want.
Catching at runtime is IMO not much different than panicking on the field access and IMO it's not enough.
> This is checkable at run time
Not sure how you check that a panic cannot occur at runtime without panicking in the first place...
> It's very similar to finding double-lock mutex deadlocks, though.
I'm not sure how they are similar. Last time I checked mutexes still required an explicit `.lock()` to be locked.
> Problems of this class are all of the form "this thing here conflicts with that thing way over there", and users need to know both ends of the conflict. The Rust borrow checker is good about that.
The last sentence doesn't make sense. You wanted to use `Rc`, `Weak` and `RefCell` precisely to avoid the kind of restrictions that are needed for the borrow checker to perform its analysis. Either you keep those restrictions and you have reference semantics or you discard them and are forced to perform runtime checks. There's no free lunch.
Your arguments basically boil down to hypothetical compile time check that doesn't exist or to arguing that hidden runtime checks are fine because you can test the code in debug mode to hopefully catch them failing. Neither of them are convincing enough.