> The data structure never moves an element once allocated
Yours will reallocate every so often, invalidating element references. append_only_vec requires only `&self` to push, and can also be used concurrently. Adding these abilities requires unsafe, so it wants its own module to uphold invariants on private members. Add an efficient well-tested impl and several other traits you might want, and a shared crate is entirely reasonable.
> Yours will reallocate every so often, invalidating element references. append_only_vec requires only &self to push,
Then the crate is lying about its intentions or performing black magic using RefCell under the hood to go behind the user's back. A vec is a vec. If I don't want re-allocations I will use .with_capacity() and cap it or use a plain array.
Also the data has to be changed somewhere to happen, and I'd rather the API be honest and give me &mut self than lie and say &self.
> you can push to the vec even while holding references to elements that have already been pushed.
Expressing this in Rust (without leaking references to a dropped container) means taking &self. It's true that the container struct itself (chunk pointers, len) is mutated, but the compiler has no distinction between this and the pointee data, so you use ..Cell. It does allocate, there's no capacity limit, but it guarantees stable pointers to existing items.
Yours will reallocate every so often, invalidating element references. append_only_vec requires only `&self` to push, and can also be used concurrently. Adding these abilities requires unsafe, so it wants its own module to uphold invariants on private members. Add an efficient well-tested impl and several other traits you might want, and a shared crate is entirely reasonable.