It would be nice if methods could be added to Vec and other common collections that return an error when they are unable to allocate memory. This would make them usable in kernels and microkernel servers and other programs which cannot panic when out of memory.
Looking at Vec, this would mean duplicating extend_from_slice, resize, split_off, append, push, insert, reserve_exact and reserve. I suggest a naming the new methods with a try_ prefix. To avoid having these new methods cluttering up the API, we could require them to be explicitly imported.
2 Likes
More generally, I think it’s nice to have non-panicking versions of all standard library functions (and a module with non-panicking versions of all built-in operations, like integer division), beside the more handy regular panicking ones.
Then you can add something like #![deny(panic_functions)] at the top of a module, to enforce of the usage of just the less handy non-panicking versions (but some way to exit the program is still needed).
3 Likes
Since Vec exposes its implementation, I recommend putting these methods in a separate package on crates.io.
It’s much easier to upload a package than try to push through an addition to std.
Since Vec exposes its implementation, I recommend putting these methods in a separate package on crates.io.
The only problem with this being that the allocation system is unstable, so you can't use Rust's allocator.
I’m in favor of this in concept. I’ve been working on a little no_std framework for realtime programming that adapts the core collections with a different API. Although my model doesn’t require it right now, it would give me more options and make the code more robust. I don’t even need them to be stable.
It would be nice if whatever approach we took here was unified with all the other places that may fail to allocate memory. I’m thinking of generic heap allocation (Box::new), and indeed simple stack expansion.
In other words, I think adding try_ versions of a bunch of the collections functions addresses is heavy-weight and addresses only one point where memory allocation may fail, and is not the direction to follow. I think I’d counter-propose putting this in a separate “embedded” fork of the collections (and heap) library where the API could be customised around handling malloc failures and evolved independently.
3 Likes
@gus yes, indeed. As I was thinking about my realtime programming requirements I realized that I don’t even want the future Rust box syntax - I want to control all access to allocation; language features that access the allocator directly bad.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.