UnwrapUnreachable

2 minute read Published: 2025-12-23

I found Zk’s article on the three kinds of .unwrap() published on 2024-10-13 interesting. Following this article he published an unwrap_todo crate for his main usecase, that is to say, rapid prototyping and using .unwrap() to keep going on the main idea and removing .unwrap() managing errors afterwards. Using .todo() makes this last move easier and one can even make a Clippy rule not to forgot any .todo().

He did not publish a crate for the unreachable usecase that is to say the case when you use .unwrap() intentionnaly because you know that your code can not panic. I use some .unwrap() intentionnaly in tests for instance. There the input data is mastered and I know that the code will always return Ok() or Some(). Better: if it doesn’t I absolutely want the code to panic!

As a non english native I find .expect("Error in regex") not so smooth because we are not expecting an Error in regex here, quite the opposite in fact. So I copied and modified the unwrap_todo and made an unwrap_unreachable crate to test if using this is better or not than using .unwrap() or .expect("Not this").

I tried it in httpdirectory for instance in static LazyLock and I’m not sure that it improves readability but it may highlight developer’s intention (to others - obviously I know my intentions) and that this is not a forgotten .unwrap().

What do you think ? Is it better or worse ? Do feel .except("Not this") is enough ?