4 ms·

It seems a serious shortcoming if you can't allocate String or Vec using a custom allocator? Presumably you can pass an arena parameter to create the custom all

It seems a serious shortcoming if you can't allocate String or Vec using a custom allocator? Presumably you can pass an arena parameter to create the custom allocator? There's plenty of room between <unlimited heap> and <preallocated>, I don't really understand why, e.g., you couldn't have a pool for a particular usage of String, or fixed size objects? Also, introspection to ask which pool an object is allocated on, how much space is available (units for fixed size, largest hole for variable size)? Is it just a syntax choice or is there a rusty reason not to have a thread-local list of allocators?

steveklabnik 6y ago
It's just time; we have stabilized the interface for the single global allocator, but the more general allocation API is still being worked on. You can do all of these things for your own data structures, but the ones in liballoc shipped without that support, because we had to get Rust 1.0 out the door. Now support is being retrofitted, and that's part of why doing so was okay before; the plan to do so in a reasonable way existed at stabilization time.
gpm 6y ago
There's nothing special about String other than it's in the standard library. It doesn't even have special cased syntax (&str does have special syntax, it doesn't allocate). String does need to know how to deallocate itself, so the compiler has to know what allocated it. It can be moved between threads, so a thread local allocator doesn't work. If you want a String type which is allocated differently, or which stores a pointer to its deallocate, you can easily implement that as a new type by hand. (The standard library types might some day become generic over allocator, which would allow statically using a different allocator with the same api. The compiler would then force you to keep track of which allocator your string was allocated with).

steveklabnik 6y ago

It's just time; we have stabilized the interface for the single global allocator, but the more general allocation API is still being worked on. You can do all of these things for your own data structures, but the ones in liballoc shipped without that support, because we had to get Rust 1.0 out the door. Now support is being retrofitted, and that's part of why doing so was okay before; the plan to do so in a reasonable way existed at stabilization time.

gpm 6y ago

There's nothing special about String other than it's in the standard library. It doesn't even have special cased syntax (&str does have special syntax, it doesn't allocate). String does need to know how to deallocate itself, so the compiler has to know what allocated it. It can be moved between threads, so a thread local allocator doesn't work. If you want a String type which is allocated differently, or which stores a pointer to its deallocate, you can easily implement that as a new type by hand. (The standard library types might some day become generic over allocator, which would allow statically using a different allocator with the same api. The compiler would then force you to keep track of which allocator your string was allocated with).