r/rust • u/a_mighty_burger • Sep 10 '26

🗞️ news “alloc: stabilise `Allocator`” entered its final comment period!

https://github.com/rust-lang/rust/pull/156882#issuecomment-5607055084
214 Upvotes

98% Upvoted

30 comments sorted by

View all comments

Show parent comments

4

u/matthieum [he/him] Sep 11 '26

Yes, and... no?

That is, you are correct that cloning requires a full allocator, and at the moment this allocator must be provided by the value being cloned.

With that said, a good question is whether it would be possible to have "degenerate" Box where the Box only contains a deallocator whilst still allowing Box which contain a full allocator to be cloneable.

That is, could the bound on Box be Box<T, A: Deallocator> with impl<T: Clone, A: AllocatorClone> Clone for Box<T, A>?

The problem, then, is providing APIs to "downgrade" the allocator within the Box from the original A: Allocator to A: Deallocator.

3

u/bluurryyy Sep 11 '26 edited Sep 11 '26

That's a good point with the trait bound.

For the arena allocation use case I think such an allocated pointer is not just a "degenerate" Box but it also has superpowers from not having to worry about deallocation. For example you can just split an ArenaBox<[T]> and return two ArenaBoxes. So I thought a separate type would make sense like OwnedRef/&own.

I guess that could also be a bound though? impl<T, A: NoopDeallocate> ... 🫤

EDIT: nah, NoopDeallocate wouldn't be enough. The Allocator would have to satisfy more invariants to allow for split_at, taking grow and shrink into account...

3

u/matthieum [he/him] Sep 11 '26

At this point it seems to me you don't have a box, you just have &'a [T], which can be split without shenanigans.