NonZeroLayout for Allocator

Proposal

Problem statement

The current allocator trait takes arguments of type Layout, which can be zero-sized. However, many allocators do not support zero-sized allocations, and must manually implement a ZST check when implementing the trait.

A nonzero check it can't be elided when allocating via &dyn, and having an allocator on the other side of a crate boundary might mean it isn't. There is already special handling for ZSTs in the implementation of Vec and other containers, so sometimes these checks are redundant.

Motivating examples or use cases

Moving the ZST check to the caller side means it can pretty much always be elided even if the allocator is opaque.

Solution sketch

pub struct NonZeroLayout {
    size: NonZeroUsize,
    align: Alignment,
}

// existing Layout type acts as the "builder" for the NonZeroLayout type
impl Layout {
    pub fn non_zero(self) -> Option<NonZeroLayout> {
        ...
    }
}

pub unsafe trait Allocator {
    fn allocate(&self, layout: NonZeroLayout) -> Result<NonNull<[u8]>, AllocError>;
    unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: NonZeroLayout);
}

Alternatives

We could also provide "convenience" functions which can handle ZSTs:

pub unsafe trait Allocator {
    fn allocate_maybe_zst(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError> {
        if let Some(layout) = layout.non_zero() {
            self.allocate(layout)
        } else {
            Ok(NonNull::slice_from_raw_parts(NonNull::dangling_mut(), 0))
        }
    }

    // likewise for deallocate
}

and allocators which handle ZSTs without issue can override the implementations.

Links and related work

• zulip

Prior wg discussions decided against this, but more recent discussions support it

• https://github.com/rust-lang/wg-allocators/issues/16
• https://github.com/rust-lang/wg-allocators/issues/38

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

Start with the proposal's Allocator and NonZeroLayout signatures, then read the linked wg-allocators issues and the Zulip discussion for prior design context. This is an API design proposal awaiting libs-api review rather than a self-contained implementation task; done would require a team decision before any implementation can be scoped.