|
> The problem is that because they're not in the standard library, you're going to have a hard time using those data structures with any other community libraries. No, all the Rust standard library collections do in fact have the same feature, you can in fact Vec::new_in(SomeAllocator) - my guess is that you'll say "Ah, but that's not yet in stable Rust" and that'd make sense in other contexts but it's a weird objection when the entire Zig language still isn't 1.0. If you wanted to write a function which takes a container and adds things to it, which I wouldn't recommend, in Rust you'd write that as a polymorphic function, so it'll just get monomorphized for the SomeAllocator variant. The use of FixedBufferAllocator here is absurd, indeed it's hard to think of non-absurd uses for this allocator, it's a toy because it has no reclamation. ArrayList has a slightly weird variation on the 1.5x growth pattern, for a large T the ArrayList<T> will grow something like 1, 2, 4, 7, 11, 17, 26, etc. But with your 1024 byte FixedBufferAllocator, the older sizes are just discarded so somewhere around 62 or so items it'll blow up, all the rest of the space was just thrown away and so the growth fails Overall this not only doesn't do what you said you were doing originally (it's not actually a stack† allocated growable array, those simply don't exist), it also doesn't do the thing you ostensibly claim it's useful for either, so much of Zig feels like this. † Edited: For a few minute this said "heap" due to a thinko |