-
Notifications
You must be signed in to change notification settings - Fork 143
Consider panicking in ArrayVec::remove
instead of returning an Option
#45
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
Comments
Also in |
I am very skeptical of an API that both panics and returns Result. |
Why? They're different classes of errors – see e.g. the |
Thanks for the example. (Bug rust-lang/rust/issues/42034 is about what to do with that. Not having it documented is of course the worst of both worlds 😄) Returning a Result signals that the function uses Results for its error handing; so it's simpler and more straightforward if it has no other error cases than the ones visible in the type system. I understand the contract violation argument, that it's a whole different class of error, but it does make a more complicated rule for the user to understand. So as a guideline / first start, I prefer either wholly panic or wholly Result for error handling in a single method. |
A version bump would make this change possible:
Vec
panics on out-of-bounds indices:Vec::remove
.The text was updated successfully, but these errors were encountered: