4 ms·

NieDzejkob is correct: In Rust, shadowing a variable has no effect on when the destructor of the previous value runs. Thus there's no problem with retaining a r

NieDzejkob is correct: In Rust, shadowing a variable has no effect on when the destructor of the previous value runs. Thus there's no problem with retaining a reference to the previous value: let a_string = String::from("foo"); let retained_reference = &a_string; let a_string = String::from("bar"); dbg!(retained_reference); dbg!(a_string); Prints: [src/main.rs:5] retained_reference = "foo" [src/main.rs:6] a_string = "bar" Similarly, "non-lexical lifetimes" have no effect on when a destructor runs. The compiler will infer short lifetimes for values that don't need to be destructed (don't implement Drop), but adding a Drop implementation to a type will force every instance's lifetime to extend to end of scope. (Though as in C++, temporaries are still destroyed at the end of the statement that created them, if they're not bound to a local variable.) The only exception to this rule that I'm aware of is what you mentioned about move semantics: Moving a value means that its destructor will never run. That's the big difference from C++. Everything else to do with destructors is very similar, as far as I know.

tialaramex 5y ago
To my mind, move semantics being "the only exception" is a pretty bad joke. Unlike C++ Rust's assignment semantics are moves. So, you're not opting in to anything here as with C++ move, this is just how everything works. For example, if you were to make the second a_string mutable, and then on the next line re-assign it to yet a third string containing "quux", the "bar" string gets dropped immediately, as a consequence of move semantics again. In C++ you'd have to go write a bunch of code to arrange that, although I believe the standard library did that work for you on the standard strings - but in Rust that's just how the language works, you assigned a new value to a_string so the previous value gets dropped.
- oconnor663 5y ago
  > In C++ you'd have to go write a bunch of code to arrange that I don't think it's quite that bad. If you define a new struct or class that follows the "Rule of Zero (or 3 or 5)", the copy-assignment and move-assignment operators will have reasonable defaults. For example, the following Rust and C++ programs make the same two allocations and two frees. Rust: struct Foo { m: String, } fn main() { let mut x = Foo { m: "abcdefghijklmnopqrstuvwxyz".into(), }; x = Foo { m: "ABCDEFGHIJKLMNOPQRSTUVWXYZ".into(), }; } C++: struct Foo { string m; }; int main() { auto x = Foo{"abcdefghijklmnopqrstuvwxyz"}; // Foo's default move-assignment operator is invoked on the temporary. x = Foo{"ABCDEFGHIJKLMNOPQRSTUVWXYZ"}; } The high-level "you assigned a new value so the previous value gets dropped" behavior is indeed what's happening, and it's automatic in most cases. But when we do voilate the Rule of Zero and override the default constructors/operators, things get quite complicated, and it's easy to make mistakes. (Also in general we often get more copies than we intended, when we're not dealing with temporaries.) The "moves are implcit and destructive, and everything is movable" behavior in Rust is substantially simpler and often more efficient, and personally I strongly prefer it. But I'll admit that trying to contend with destructive moves without the borrow checker would probably be painful.

tialaramex 5y ago

To my mind, move semantics being "the only exception" is a pretty bad joke. Unlike C++ Rust's assignment semantics are moves. So, you're not opting in to anything here as with C++ move, this is just how everything works. For example, if you were to make the second a_string mutable, and then on the next line re-assign it to yet a third string containing "quux", the "bar" string gets dropped immediately, as a consequence of move semantics again. In C++ you'd have to go write a bunch of code to arrange that, although I believe the standard library did that work for you on the standard strings - but in Rust that's just how the language works, you assigned a new value to a_string so the previous value gets dropped.

oconnor663 5y ago
> In C++ you'd have to go write a bunch of code to arrange that I don't think it's quite that bad. If you define a new struct or class that follows the "Rule of Zero (or 3 or 5)", the copy-assignment and move-assignment operators will have reasonable defaults. For example, the following Rust and C++ programs make the same two allocations and two frees. Rust: struct Foo { m: String, } fn main() { let mut x = Foo { m: "abcdefghijklmnopqrstuvwxyz".into(), }; x = Foo { m: "ABCDEFGHIJKLMNOPQRSTUVWXYZ".into(), }; } C++: struct Foo { string m; }; int main() { auto x = Foo{"abcdefghijklmnopqrstuvwxyz"}; // Foo's default move-assignment operator is invoked on the temporary. x = Foo{"ABCDEFGHIJKLMNOPQRSTUVWXYZ"}; } The high-level "you assigned a new value so the previous value gets dropped" behavior is indeed what's happening, and it's automatic in most cases. But when we do voilate the Rule of Zero and override the default constructors/operators, things get quite complicated, and it's easy to make mistakes. (Also in general we often get more copies than we intended, when we're not dealing with temporaries.) The "moves are implcit and destructive, and everything is movable" behavior in Rust is substantially simpler and often more efficient, and personally I strongly prefer it. But I'll admit that trying to contend with destructive moves without the borrow checker would probably be painful.