wg-allocators

Yeah that makes sense. Maybe arenas will be viable once the working group makes progress on allocators. https://github.com/rust-lang/wg-allocators

For people that might be confused, setting a custom global allocator is possible in stable, but the Allocator trait isn't yet, so specifying the allocator for a specific instance of a Vec isn't possible in stable. https://doc.rust-lang.org/std/alloc/index.html#the-global_al... https://github.com/rust-lang/wg-allocators

https://rust-lang.github.io/rfcs/1974-global-allocators.html was the original RFC. My vague understanding is that there's a working group https://github.com/rust-lang/wg-allocators The further I get from working on Rust day to day, the less I know about these things, so that's all I've got for you.

If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers". Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48). Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).

You can of course use arenas in Rust just like in C. I think the parent was talking about support for using arenas as the memory for stuff like built-in containers (dynamic arrays, hash maps, etc.): https://github.com/rust-lang/wg-allocators

I think the plan is to support this kind of thing with per-collection allocators - https://github.com/rust-lang/wg-allocators

Work on custom allocators is underway, some of the std data structures already support them on nightly. https://github.com/rust-lang/wg-allocators/issues/7

And here's the working group's repo: https://github.com/rust-lang/wg-allocators

Thanks for linking those projects and for "yet", which led me to the pages below https://rust-lang.github.io/rfcs/1398-kinds-of-allocators.ht... https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/wg-allocators

There is some ongoing work towards custom allocators for containers in Rust std. [1] Right now you could also go no_std (you still get the core library, which does not contain any allocating data structures) and use custom containers with a passed in allocator. Zig is definitely a cool language, and it will be interesting if they can come up with good solutions to memory management! But sentences like these in the documentation [2] would make me prefer Rust for most low level domains (for now): > It is the Zig programmer's responsibility to ensure that a pointer is not accessed when the memory pointed to is no longer available. Note that a slice is a form of pointer, in that it references other memory. ... > ... the documentation for the function should explain who "owns" the pointer [1] https://github.com/rust-lang/wg-allocators [2] htt

A short overview: 1. Rust the language knows nothing about allocation. If you care about this behavior, it mostly limits the code of others' that you can use, but you can always write your own versions of things that respect fallible allocations. 2. Rust's standard library assumes memory is infallible. This is partially because it's a good default, and partially because our allocator API was not ready yet. 3. We've been working on the allocator API. 4. We have a rough plan for parameterizing data structures over allocators. 5. If this topic is of interest to you, https://github.com/rust-lang/wg-allocators is where to get involved.