> Collections are not parametrized by an allocator, like in C++ or (future) Rust.
What does he mean by this?
Psuedo-Rust code here, showing off both styles.
Parameterized by an allocator:
struct Foo {
// ...
}
impl Foo {
fn new() -> Foo {
// do something to make a new foo, calling functions via A
}
}
contrast with "an allocator is passed in explicitly to every method which actually needs to allocate." struct Foo {
// ...
}
impl Foo {
fn new(a: A) -> Foo {
// do something to make a new foo, calling functions via A
}
}
(EDIT: "new" was a bad choice for me to pick here, see the child comment that uses 'put' instead; I was not trying to suggest that the allocator only parameterizes a constructor, but any call that would need to allocate.)Thanks for the example. I wasn't aware this is something that was planned for Rust, seems like a pretty large breaking change. Interesting!
Nothing is breaking! The change isn't a move to a zig-like style, but instead, that in today's Rust, you have
struct Foo {
// ...
}
and not struct Foo {
// ...
}
This isn't breaking because there is a default type provided for A.The handwave is over "Today's Rust", as this machinery has already landed, in a sense, it's just not really possible to use with the standard library because the allocator API isn't fully stable.
Here's an actual example: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html See that "A = Global"?
I see. I'm interested in the motivation and design goals behind it, is there something that spells those out? The only thing I could find quickly is this [0].
[0] https://internals.rust-lang.org/t/why-bring-your-own-allocat...
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.