# Notes + Interviews on Fallible Collection Allocations

**URL:** <https://internals.rust-lang.org/t/notes-interviews-on-fallible-collection-allocations/5619>\
**Category:** Uncategorized\
**Created:** [July 26, 2017, 1:59pm UTC](https://internals.rust-lang.org/t/notes-interviews-on-fallible-collection-allocations/5619 "2017-07-26T13:59:52Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![joshlf](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/joshlf/32/3815_2.png) [@joshlf](https://internals.rust-lang.org/u/joshlf)\
**Post date:** [July 26, 2017, 6:37pm UTC](https://internals.rust-lang.org/t/notes-interviews-on-fallible-collection-allocations/5619/8 "2017-07-26T18:37:29Z")

</div>

> [@Gankra](#):
>
> For all considered proposals, I’ll be using a strawman error type, which I’ve only thought about a little:
> 
> ```rust
> enum AllocFailure { Exhausted, CapacityOverflow }
> 
> ```
> 
> Note that the allocator API defines:
> 
> ```rust
> 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](https://github.com/rust-lang/rust/pull/42313#issuecomment-307171933), 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](https://doc.rust-lang.org/nightly/alloc/allocator/enum.AllocErr.html), "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.

```rust
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.

---

_[View the full topic](https://internals.rust-lang.org/t/notes-interviews-on-fallible-collection-allocations/5619)._