Hacker News new | ask | show | jobs
by Cyph0n 2281 days ago
Oh, I never even considered this... But how would Rust ever be able to signal allocation failures in such cases?
2 comments

Same as any other failure; functions that may try to allocate memory and fail will return a Result<T, E> instead of just a T.
Which would be pretty painful for everyone not working in a memory-constrained environment (at a guess, that's most developers). Much like std:println! panicking instead of returning an error, ergonomics are important too a lot of the time.
It obviously wouldn't be the default (it couldn't be, in fact, since the existing APIs are set in stone short of memory unsafety).

The way it'd work is either you'd have two different collections entirely, one which'd signal and one which'd panic (the latter possibly being built atop the former) or every method which can panic on allocation failure would also have a panic-safe alternative.

Example: https://github.com/rust-lang/rust/issues/48043 similarly Vec could gain `try_push`, `try_append`, `try_insert`, `try_split_off`, …

Which is why you offer two APIs: one that panics, & one which returns Result or Option
Eg. with Vec, every operation that may trigger reallocation should return Result.