4 ms·
Oh, I never even considered this... But how would Rust ever be able to signal allocation failures in such cases?
by Cyph0n 7y ago
Oh, I never even considered this... But how would Rust ever be able to signal allocation failures in such cases?
- steveklabnik 7y agoSame as any other failure; functions that may try to allocate memory and fail will return a Result<T, E> instead of just a T.
- swiftcoder 7y agoWhich 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.
- __s 7y agoWhich is why you offer two APIs: one that panics, & one which returns Result or Option
- masklinn 7y agoIt 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 https://github.com/rust-lang/rust/issues/48043 similarly Vec could gain `try_push`, `try_append`, `try_insert`, `try_split_off`, …
- Sharlin 7y agoEg. with Vec, every operation that may trigger reallocation should return Result.