Your response is kind of harsh, and you're making a bit of an unsympathetic straw man out of what I said.
IMHO there's a qualitative difference in the programmer's expectations when indexing a slice vs calling a function which has been explicitly written to return an error condition. Years of convention causes us to expect indexing errors and to write defensively. But the implied contract of a Rust function with a Result is that the user should do probably do something with the result other than panic in most cases.
I agree that panicing is a legit option. And I agree with the scenarios laid out in the article. And I also don't think lint is the right way to handle it.
But I'm currently in a codebase that is full of unwraps all over -- which the developers did for expediency "get this thing shipped" reasons -- and that (and other codebases I've seen) is what leads me to the conclusion that the ergonomics of putting unwrap right out there in our faces aren't ideal.
Hell, even calling it "result_or_panic" would have perhaps made casual users of it pause and think about what they were doing. There are likely syntactical tools that could have been put in place to really make the user think before creating a panic.
(FWIW safety isn't my primary reason for preferring Rust. I'd be fine with "C++ with a ML-style type system." The general tamping down of footguns is great, though)
Fair enough. Sorry about the harshness. Although you respond to the slice indexing problem with some reasoning about expectations (I'm not so sure I buy that), you do leave off the alloc and arithmetic aspects. I don't think arithmetic, for example, is something we've been trained to be guarded about. But it can be a source of bugs too.
Anyway, I'm sympathetic to the plight of finding yourself in a codebase full of bugs. But I think 'unwrap()' gets a bad rap here. It just so happens that it makes those bugs easily visible and it happens to be a common manifestation of it.
Personally, I don't think a different name for 'unwrap()' would have helped things. One common suggestion is 'or_panic()'. If we could go back and do it all over again, I think 'or_panic()' would be worth a shot. But I think that ship has sailed.
IMHO there's a qualitative difference in the programmer's expectations when indexing a slice vs calling a function which has been explicitly written to return an error condition. Years of convention causes us to expect indexing errors and to write defensively. But the implied contract of a Rust function with a Result is that the user should do probably do something with the result other than panic in most cases.
I agree that panicing is a legit option. And I agree with the scenarios laid out in the article. And I also don't think lint is the right way to handle it.
But I'm currently in a codebase that is full of unwraps all over -- which the developers did for expediency "get this thing shipped" reasons -- and that (and other codebases I've seen) is what leads me to the conclusion that the ergonomics of putting unwrap right out there in our faces aren't ideal.
Hell, even calling it "result_or_panic" would have perhaps made casual users of it pause and think about what they were doing. There are likely syntactical tools that could have been put in place to really make the user think before creating a panic.
(FWIW safety isn't my primary reason for preferring Rust. I'd be fine with "C++ with a ML-style type system." The general tamping down of footguns is great, though)