8 ms·
For those you have `unreachable!()` (a hope rather than a certainty): https://doc.rust-lang.org/std/macro.unreachable.html https://doc.rust-lang.org/std/macro.
by sshine 2y ago
For those you have `unreachable!()` (a hope rather than a certainty):
https://doc.rust-lang.org/std/macro.unreachable.html https://doc.rust-lang.org/std/macro.unreachable.html
In those cases you strike a deal with the devil. The type system won't help you.
Maybe it's an acceptable tradeoff for readability and efficiency.
Maybe you could have modelled the code so it wasn't necessary.
I think you can divide the use of `unreachable!()` in two cases:
1) As a consequence of style (applying LEM to code)
2) As a consequence of low-level abstractions
One can be avoided by remodelling. The other can be tucked away behind safe interfaces.
- steveklabnik 2y agoThe unreachable macro invokes a panic. It wouldn’t be allowed if panics were not allowed.
- Fulgen 2y agoAs the other commenter said, `unreachable!()` panics. You'd need https://doc.rust-lang.org/core/hint/fn.unreachable_unchecked.html https://doc.rust-lang.org/core/hint/fn.unreachable_unchecked...
- SkiFire13 2y agoWhich is arguably even worse, because now if it fails you don't even see it! You wanted to make the code more robust and ultimately made it less.
- sshine 2y agoYes, I'm not saying `unreachable!()` isn't a `panic!()`. And I am also not arguing for the use of `unreachable_unchecked!()`. I am only arguing that in all the other cases mentioned, you can simply avoid panics.
- SkiFire13 2y agoThe problem however is that a generic "panic" lint will trigger on these as well. Which will be pretty annoying. Combined with the fact that such a lint will have to see through functions in other crates (otherwise `unwrap` and indexing won't be linted) will make this pretty annoying. I hope maintainers won't be nagged to remove lecit panics like these just because the lint annoys some dependents...