You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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 onrepr(transparent)
structs, preventing a non-ZSTallocator: 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 text was updated successfully, but these errors were encountered: