`AllocError` does not store additional information

[Zymlex]

It would be nice if AllocError became a trait (or associated type) for which each implementation could add additional information, such as the cause of the error and something else.

[CAD97]

Not a trait, but associated type.

The error type for collections' try_reserve contains reserved API space for adding an associated allocation failure error type, so this is at least possible.

The main questions then are

• object safety — dyn Allocator for dynamic allocators working is a key design goal;
• defaulting — default provided methods may want to create an error, so either they need to only be defaulted when the error type is defaulted, or there needs to be a default trait bound guaranteeing default constructability; and
• what trait bounds do we put on the associated error type and where do we require them — notably, the Error trait only just very recently was made available in core.

Plus, for the majority of cases, allocators won't have any context to provide beyond just the size of the requested allocation, which shouldn't be part of the error type in order to avoid the performance overhead in the typically very hot code.

Plus, by construction, this wouldn't be available to anything using the global allocator. The utility of custom errors is marginal due to that.

[Urhengulas]

It would be nice if AllocError became a trait (or associated type) for which each implementation could add additional information, such as the cause of the error and something else.

@Zymlex Out of interest: What additional information are you thinking about? What is your context for that? I am recently thinking about this a lot in the context of safety-critical software.

[Zymlex]

At least the error details. For example, on Windows, HeapAlloc provides two error causes STATUS_NO_MEMORY and STATUS_ACCESS_VIOLATION. The first in some cases is not critical and can be solved, the second is hinting at a possible bug and problems. I do not exclude that some allocators may provide additional information about the error.

In cases where the data size is unknown, necessary to allocate space for a future error in advance (on application launch). It would be nice if it were possible to specify whether this feature is enabled and how much memory to allocate in advance.

[Urhengulas]

Thanks.

You might want to have a look into the previous discussion about an associated error type https://github.com/rust-lang/wg-allocators/issues/23. It kind of ended in "sounds generally interesting, but no one has a concrete usecase" (see https://github.com/rust-lang/wg-allocators/issues/23#issuecomment-584204175).

[kornelski]

In terms of use-cases, I would like to remove Layout from TryReserveError{Kind} types (to reduce code bloat from large Results around finish_grow and try_ functions), but still leave possibility of getting more detailed error information for users who really want this.

From what I've seen, most OOM handlers only care about size, and even then only as an FYI to print it as a potential clue for analyzing an OOM abort. Use-cases for including Layout.align are even weaker — mainly as a clue for guessing that OOM happened due to types having alignment is so incredibly large it can't be satisfied due to technical limits of the allocator, or address space fragmentation, but that case is so exceptionally rare, that anybody using such trick will already know that at the call site anyway.

https://internals.rust-lang.org/t/questioning-usefulness-of-alignment-in-oom-errors-and-handlers/20233/1

But one-size-fits-all TryReserveError is not going to work for everyone. The Layout despite being relatively large, is not actually that informative, because it's only for guessing the real reason. It's not supplied by the allocator itself. So guessing that maybe OOM was due to large alignment is not as good as having allocator return some CustomError::AlignmentWasTooLargeIndeed.

I can imagine users adding verbose information to allocation errors in debug or beta-testing builds, and switching it to zero-sized types for production builds. Having a custom type for errors would make it possible, instead of TryReserveError being too big for some, and not detailed enough for others.

121