3 ms·
> I was given the impression that as soon as the lifeline was out of scope, the resources were cleaned. And you are right. Even though GP is almost right, lif
by kaoD 12y ago
> I was given the impression that as soon as the lifeline was out of scope, the resources were cleaned.
And you are right.
Even though GP is almost right, lifetimes do interact with destructors and, in fact, dictate when values go out of scope and hence when drop (Rust destructor) is called.
> So it acts like a GCed language in most ways, in that, most of the time you don't have to worry about cleaning up after yourself
Nope. In Rust you almost always have to worry about cleaning up although not explicitly, but via lifetime and ownership management.
Sometimes you're lucky and those lifetimes can be inferred, but you still have to think about ownership a lot.
> and that it is hard to memory leak.
But not in the same way.
In Rust you can memory leak only when:
- Using GC like Arc or Rc with cycles.
- On blocks/fns marked as unsafe (which are mandatory for unsafe operations).
- Running into a Rust bug.
- dbaupp 12y ago> And you are right. Even though GP is almost right, lifetimes do interact with destructors and, in fact, dictate when those are called. It's actually the other way around: scoping dictates when destructors are called and the length of the lifetimes of borrowed pointers etc. That is, the main factor is scoping, and lifetimes just reify that into something the programmer and compiler can reason about, to ensure safety.
- kaoD 12y ago> That is, the main factor is scoping Sorry, I meant (and I guess myrryr meant too) ownership instead of lifetimes. I was in the process of ninja-editing my comment when I saw your reply :P Ownership dictates when a value goes out of scope and hence when the destructor is called.