[nitrogen]

While quotemstr's reaction is over the top, I do see the need to have a memory allocation approach that can handle OOM gracefully. Many types of software that could benefit from Rust's compile-time safety will want to allocate right up to the limit of available memory, such as audio/video processing software where more memory equals more simultaneous effects and less I/O.

I am endlessly frustrated by poorly designed audio software that aborts without saving if an OOM occurs. At the very least, a process should have the oppprtunity to save its state to disk, or ideally continue operating at a reduced capacity (e.g. a video codec might use fewer reference frames) after freeing some resources.

[Manishearth]

> I do see the need to have a memory allocation approach that can handle OOM gracefully.

Do you find anything wrong with inserting an allocator that panics on OOM (IIRC the default one aborts on OOM) and using `std::panic::recover` to catch the panic? This is the same as throwing and catching an exception. Note that `recover()` is designed to be exception safe by default.

(There soon will be a way to make std heap APIs like box and vec use Result, which might be neater)

[nitrogen]

I don't myself, no, but I haven't dived into Rust yet. I'm assuming that recovery can happen at a point where data can still be saved.

[Manishearth]

Yeah.