Re-opening deprecating Option::unwrap and Result::unwrap

language design
122

I'd say that what you'd really want is

impl<T, E> Result<T, E> {
   fn assert_ok(self) -> T; 
   fn assert_err(self) -> E; 
}

impl<T> Option<T> {
   fn assert_some(self) -> T; 
   fn assert_none(); 
}

It would be nice if those could be postfix macros which even allowed something like

let f = foo().assert_ok!("nice message {}", "with formatting");

or even

let f = bar().assert_ok!(err => "the error code was {}", err.code);
123

FWIW, without providing the error value, there's not much difference[1] between that and

let Ok(f) = foo() else { panic!("nice message {}", "with formatting") };

but yes, a postfix .unwrap! would be a very nice convenience. There are just many issues with type-dependent macro name lookup that make this an unlikely feature. (.unwrap! could potentially be non-type-dependent by being generic over Try semantics, but .assert_ok! wouldn't want to be a global name that only accepts Result receivers. You could maybe argue justifying it from the fact that Ok is already in the prelude, but that's a rather weak justification.)

  1. At least, if we stray from rustfmt's default style, which always makes the else block an indented block. ↩ī¸Ž