Support some of the unstable/unsafe features from `std::Vec`

[Oppen]

It would be nice if the API mapped closer to std::Vec.
Methods like assume_init or set_len or the ability to use custom allocators are used in a project for which EcoVec is otherwise a perfect fit to reduce memory fragmentation.

[laurmaedje]

I'm open to exposing more low-level methods in principle. However, we need to be very careful in cases where ecow needs extra guarantees. Especially things like set_len which require the user to reason about the internal state of the Vec are a bit trickier since the EcoVec may perform clone-on-write, which for instance can change its capacity. Regarding the other mentioned one: I can't find an assume_init method for std::vec::Vec.

[Oppen]

assume_init is part of MaybeUninit, more related to the Arc-like characteristics. I guess with set_len and by using the spare capacity you get equivalent dynamics as with assume_init in an uninitialized slice.

[laurmaedje]

I'm not yet entirely sure how the assume_init thing would look like. But it's also nightly-only in Rust, so maybe a bit early.

[pedrodesu]

How do we feel about the current status or direction for this issue?

Are there any specific unstable, unsafe, or nightly-only/feature-gated functions from Vec that are currently desired or open to being implemented for EcoVec? From my understanding from #54, I suppose into_raw_parts, into_parts, from_raw_parts and from_parts constitute such an example? I'd be open to making such a contribution.

[laurmaedje]

The into_raw_parts and into_parts API feel redundant to me and I suspect if Rust were to start from scratch, it would not add both (I may be wrong on that). But having just one of them I would be okay with. The NonNull one seems nicer. So basically into_parts(self) -> (NonNull<T>, usize) and from_parts(NonNull<T>, usize). Having the capacity in there does not make sense for EcoVec I think.

[pedrodesu]

That seems correct. I'm still curious on whether there are other nightly/experimental functions that we wanna bring to EcoVec though? Such as the allocator API, for instance.

[laurmaedje]

I think I would probably leave the allocator API out until someone actually has a use case. Any other ones you have in mind?

[pedrodesu]

allocator_api is a good priority, especially for Typst's end I believe. Because EcoVec is typically used for heavy ASTs (such as is my case and Typst's!), letting users back it with arena allocators like bumpalo turns allocation into a simple pointer bump and eliminates heap lock contention completely.

For hot paths, push_within_capacity is an easy win. In builder patterns where capacity is already guaranteed, it strips out capacity checks and CoW ref-count branching entirely. When ref_count == 1, the call lowers directly to a single pointer write and a length increment.

Exposing spare_capacity_mut allows direct batch writes without paying the tax of pre-zeroing memory or running push checks per element.

These are some ideas.

[laurmaedje]

@pedrodesu I'm not sure I get the point in your second paragraph: How would push_within_capacity strip out capacity checks? The capacity check is literally the first line in its std implementation.

Your comment also appears to be at least partly AI-written, which leaves me skeptical as to concrete motivations. It sounds like an LLM was prompted to come up with ideas for which unstable features would make sense to implement. To me, this implies limited actual demand, but rather the abstract idea to add more features, which is not something I want to invest time into at the moment.

For this reason, I would rather not proceed for the time being, at least until other people chime in with more use cases.

[pedrodesu]

My comments are definitely not AI-written, though I use it sparingly to help me verbalise what I mean.
My intentions are very simple: They come from my personal use of this crate, as I explained with my personal motivation for the allocator_api idea, and of my desire to contribute in such an ecosystem. That is, in fact, the most significant idea that I can see in regards to pushing unstable/nightly features, as I intend to use the EcoVec with a custom allocator, and figured Typst could also use this benefit.
Regarding push_within_capacity, it is indeed true that what I said was incorrect, the capacity checks are still there, I overlooked that. What is, however, useful for this function is that it's a guarantee that when pushing through this function, no reallocation will ever happen. If used in a hot loop with a big enough reserve beforehand, we can explicitly know that we avoided reallocations altogether, which does mean avoiding reallocation cost (although not their checks, as I'm now aware that I claimed wrongfully).
With that said, I'm fine with waiting for third opinions or closing this if you will it.