Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I would imagine the normal lifetime arrangements in Rust would prevent this, the same way it prevents nesting a shorter lived pointer inside a longer lived struct when they're all from the same allocator.


OK, interesting! If I understand correctly, that means even within the arena, lifetime is tracked. That makes sense - it is Rust after all.

If each arena maintains a counter of live objects, then the arena can be dropped if it reaches zero.


In general in Rust, lifetimes enforce that references to a thing do not outlive the thing itself.

Even in unsafe code, it is possible to tie the lifetime of the allocations to the lifetime of the thing handing out the allocations, meaning that if you ever attempt to "escape" the scope, e.g. storing a shorter lifetime allocation in a longer lifetime allocation, that outer item can now only live as long as the shorter lifetime (even though it derives from the longer lifetime allocator). Any violation of this becomes a compile time error.

For example, within a function, you can have a Vec of references to local items, and although the Vec is an allocation, and COULD live forever/as long as necessary (allocations have 'static lifetime), that Vec MUST be dropped at or before when the references it contains would become invalid.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: