The current proposal for our own allocator trait does not support carrying allocator information (ie the methods do not take &self but are free standing functions). This prevents implementation of arena allocators, as they carry the space that can be allocated.
The reason that the current proposal has this limitation is #[derive(SmartPointer)]: it can only be used on repr(transparent) structs, preventing a non-ZST allocator: A field. The problem of allowing non-repr(transparent) structs under #[derive(SmartPointer)] is a complex one, see rust-lang/rfcs#3621. But it might eventually be possible to do so. This issue tracks if/when it is possible to change the allocator trait to accommodate arena allocators (and other stateful allocators).
cc @dakr
The current proposal for our own allocator trait does not support carrying allocator information (ie the methods do not take
&selfbut are free standing functions). This prevents implementation of arena allocators, as they carry the space that can be allocated.The reason that the current proposal has this limitation is
#[derive(SmartPointer)]: it can only be used onrepr(transparent)structs, preventing a non-ZSTallocator: Afield. The problem of allowing non-repr(transparent)structs under#[derive(SmartPointer)]is a complex one, see rust-lang/rfcs#3621. But it might eventually be possible to do so. This issue tracks if/when it is possible to change the allocator trait to accommodate arena allocators (and other stateful allocators).cc @dakr