-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
get_unwrap is questionable advice #3862
Comments
I also feel like this lint is questionable. Putting it in pedantic may be fine, but even then that's making a judgement on what is good code. The nursery or restriction sets may work better? |
Unwrap is not the sole cause of panics in Rust. I can totally get behind defensive coding, but If you write |
I've gotta say that I disagree with this pretty strongly. Maybe you've developed a better intuition, but in my experience doing code reviews,
If that's true, then the lint should suggest using |
I would suggest both:
|
So is this a situation where some I would have assumed |
No, it's a situation where the programmer's preference is to avoid it, and there's a good reason behind that preference that applies to everyone.
Yeah I can easily see cases where people explicitly prefer it.
We already have a lint for unwraps so if folks want to do this they can pick a lint 😄 |
Ok, so let's move it to |
On it. |
Yeah, I'm in that camp. I find |
The get_unwrap lint suggests replacing
x.get(y).unwrap()
withx[y]
. IMO, this is bad advice because the former syntax makes it clear that there's a risk of a panic, while the latter looks innocuous. It's generally good to be aware of where panics can happen. It's especially true when processing untrusted input, where a panic caused by user input is a Denial-of-Service vulnerability.I propose that we make this lint non-default at the least, and possibly consider removing it.
The text was updated successfully, but these errors were encountered: