4 ms·
Well, that whole "ref" thing just shows my ignorance of Rust. Thanks for the information. > That would leave 'ref' dangling, if even for a moment, like here. T
by borrowwhatnow 11y ago
Well, that whole "ref" thing just shows my ignorance of Rust. Thanks for the information.
> That would leave 'ref' dangling, if even for a moment, like here. That'd be bad.
I'm not sure I agree that it would be bad (except maybe from a purity standpoint). Ref is unreachable during the time it is "pointing" to the out-of-scope "val", so nothing can actually reach the out-of-scope value through ref.
- steveklabnik 11y agoIn this specific instance, with these types, sure. Imagine you had two different types, with a destructor defined, which did things. Any amount of code can run between those two things being free'd.
- borrowwhatnow 11y agoTrue, but pointers don't have destructors in C++ or Rust, I think (and in C, there are no destructors at all, obvs).
- steveklabnik 11y agoThese particular references don't, but many smart pointers do. The borrow checker doesn't currently do something different based on Drop. You can argue that it would be easier if it just made this work, but at the same time, there would be more special cases. Right now, the rule is very simple. We'll see once SEME regions and or non-lexical borrows land, though...
- Jweb_Guru 11y agoYes, you're correct. One thing people want to improve is Rust's ability to detect situations like this, where there is a dangling pointer but it can't actually affect anything. The current rules are deliberately conservative, and even with these rules we have seen a fair amount of accidental unsafety in weird syntactic edge cases that had to be fixed.