Oh yeah, arena allocation is great. I've used it a few times and it's always a huge performance improvement. The requirements are that (i) the objects you're allocating all have the same type, and (ii) they all have the same lifetime (i.e. it's okay not to free any of them while others still live).
It wouldn't. For some reason in Rust people tend to apply the term "arena" to "vector + indices" as well as the proper definition, which does have that restriction.
your (i) is incorrect (arena allocators can allocate objects of different types, and indeed one of their strong points is that they don't suffer from fragmentation) and your (ii) doesn't make sense because not freeing an object is always okay, according to conventional programming language semantics anyway
this particular arena allocator does allocate objects of different types, almost arbitrary types in fact:
the safety concern is that nothing outside the arena survive the arena if it contains a pointer into the arena. as the linked micro-book puts it, 'it shouldn't be possible for any arena-allocated [variable] to outlive the memory that it[s data]'s located on.'
> not freeing an object is always okay, according to conventional programming language semantics anyway
Conventional semantics have to hit reality eventually. Long-running programs can't just alloc forever without free, hence an arena not being the only allocator in most long-running programs.
yes, this is certainly a weak point in conventional semantics, but not relevant to this issue, which is about ensuring no dangling pointers, not about memory leaks
if you're running low on memory, switching to an arena allocator is probably a bad idea, because it will usually increase your memory requirements (by delaying deallocation longer), not decrease them
