Notes + Interviews on Fallible Collection Allocations

[joshlf]

@Gankra

For all considered proposals, I’ll be using a strawman error type, which I’ve only thought about a little:

enum AllocFailure { Exhausted, CapacityOverflow }

Note that the allocator API defines:

pub enum AllocErr {
    Exhausted { request: Layout },
    Unsupported { details: &'static str },
}

• I don’t think Unsupported should be exposed (it will instead be folded into Exhausted).
• I don’t think Layout should be exposed (it’s an implementation detail).

I'm wary of folding Unsupported and Exhausted into the same error type. I have a long comment about this here, but the TLDR is that Unsupported and Exhausted express fundamentally different ideas. Unsupported implies that the requested layout is fundamentally unsupported by this allocator, and could never be supported regardless of system resources. Exhausted, on the other hand, to quote the documentation, "strongly implies that some series of deallocations would allow a subsequent reissuing of the original allocation request to succeed."

As I discuss in the linked comment, the only reasonable response to an Unsupported error is to crash. An Unsupported error should be taken as evidence of a bug - that a given piece of code is being combined with an allocator that cannot support the allocations that the code requires. In fact, it might even be reasonable to remove the Unsupported error entirely and have Alloc's methods panic/abort on unsupported requests.

enum AllocFailure { Exhausted, CapacityOverflow }

To revisit this proposed type, what is the benefit of having CapacityOverflow be its own variant? Are there cases in which it both the case that a) a request is valid (in the sense of being supported by the allocator) but also, b) the request is too large to ever be supported regardless of system resources? CapacityOverflow seems to me to be a special case of Unsupported - an allocation request that is fundamentally unsatisfiable regardless of system resources.

EDIT: I think I may have misunderstood. Is AllocFailure intended to be an alternative to AllocErr for the Alloc trait's methods to return, or is it intended as the error type returned by fallible methods on containers (e.g., Vec::try_push)?

---

This is mostly awesome work, though! Very in favor of making progress on the infallible/fallible distinction.