Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Oppen opened this issue Apr 23, 2024 · 3 comments
Open

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

Oppen opened this issue Apr 23, 2024 · 3 comments

Comments

@Oppen
Copy link

Oppen commented Apr 23, 2024

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
Copy link
Member

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
Copy link
Author

Oppen commented Apr 30, 2024

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
Copy link
Member

laurmaedje commented May 1, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants