Comment by sshine | Hacker News Reader

Comment by sshine | Hacker News Reader

Parent Full thread

For those you have `unreachable!()` (a hope rather than a certainty):

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.

As the other commenter said, `unreachable!()` panics. You'd need https://doc.rust-lang.org/core/hint/fn.unreachable_unchecked...

Which 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.

Yes, 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.

The 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...

The unreachable macro invokes a panic. It wouldn’t be allowed if panics were not allowed.

Reply on news.ycombinator.com