[echelon]

See the immediately preceding sentence.

I'm fine with allocation failures. I don't want stupid unwrap()s, improper slice access, or other stupid and totally preventable behavior.

There are things inside the engineer's control. I want that to not panic.

[throwaway2037]

Your pair of posts is very interesting to me. Can you share with me: What is your programming environment such that you are "fine with allocation failures"? I'm not doubting you, but for me, if I am doing systems programming with C or C++, my program is doomed if a malloc fails! When I saw your post, I immediately thought: Am I doing it wrong? If I get a NULL back from malloc(), I just terminate with an error message.

[deredede]

Not GP but I read "I'm fine with allocation failures" as "I'm OK with my program terminating if it can't allocate (but not for other errors)".

[johnisgood]

I mean, yeah, if I am using a library, as an user of this library, I would like to be able to handle the error myself. Having the library decide to panic, for example, is the opposite of it.

[echelon]

If I can't allocate memory, I'm typically okay with the program terminating.

I don't want dependencies deciding to unwrap() or expect() some bullshit and that causing my entire program to crash because I didn't anticipate or handle the panic.

Code should be written, to the largest extent possible, to mitigate errors using Result<>. This is just laziness.

I want checks in the language to safeguard against lazy Rust developers. I don't want their code in my dependency tree, and I want static guarantees against this.

edit: I just searched unwrap() usage on Github, and I'm now kind of worried/angry:

https://github.com/search?q=unwrap%28%29+language%3ARust&typ...

A lot of this is just pure laziness.

[PhilipRoman]

Not to mention overcommit has become standard behavior on many systems, so you wouldn't even get a NULL unless you really tried.