Why don't you like expect? It feels pretty natural to me.

    foo.expect("already validated")

That reads as "I expect this to be already validated". Is that what you intended it to mean? Similarly,

  foo.expect("There was a problem and I had to crash")

That _reads_ as "I expect there to be a problem and have to crash". But it _means_ something totally different. It means:

  There should not be a problem, but if there were a problem
  I would crash and print out this message.

And the way to write that in readable code is

  foo.unwrap_or_else(|| panic!("There was a problem and I had to crash"))

I'm sorry if I'm misunderstanding -- if I am can you explain to me how? Because I feel like my view is diametrically opposed to yours but it's really not that subjective a matter; only one of us can be right.

You just phrase things the opposite way. I don't think it's clearly better to say the expected happy path or the unexpected sad path in a crash message.

> That reads as "I expect this to be already validated". Is that what you intended it to mean?

Yes

> foo.expect("There was a problem and I had to crash")

> That _reads_ as "I expect there to be a problem and have to crash". But it _means_ something totally different. It means:

Absolutely. That's why I'd phrase it foo.expect("foo invariant upheld")

OK, that would be nice but...what you're saying just doesn't work! The user gets an error message saying

  thread 'main' panicked at 'foo invariant upheld'

And everyone, except those who are inured to the illogic via experience, will read that as

  thread 'main' panicked because 'foo invariant upheld'

especially new users, less experienced programmers, and non-Rust programmers seeing the panic message.

Now if the Rust language made that error message say

  thread 'main' panicked at failed expectation for 'foo invariant upheld'

that might be cool. But it does not do that. It feels like you're bending over backwards trying to excuse what is clearly a wart in a beautiful language. I'm happy to continue the debate though, I am fascinated to know how I can be wrong here :)

So that's my main point, that your strategy doesn't work due to the error message. But a secondary point is that Rust documentation encourages people to use it opposite to what you suggest: I mean, just look at the first example in the Rust book. It's completely nonsensical:

  let f = File::open("hello.txt").expect("Failed to open hello.txt");

I know there was some controversy about this early on and somehow it didn't get reverted; it would be more honest if the docs would at least admit that it's "a little strange".

https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...

Playground if you want to remind yourself of the psychological experience of seeing that error message at run time with minimal effort.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Outside of tests and toy examples you're generally expected to only panic when the developer has failed to uphold an invariant, not when the user has. As a result there's generally nothing a non-rust-developer can do with the message besides post it on the bug tracker.

Right, so that's relevant to a minor incidental comment I made. But what do you think of the main points, which are

(a) If you write the message the way you suggest the printed error message is misleading, and

(b) The Rust community does not encourage using .expect() in the way you suggest; in particular the canonical Rust documentation source instructs us to use it as

  foo.expect("A thing I do not expect")

Similarly, from the rust stdlib docs for process::Command

  let hello_1 = echo_hello.output().expect("failed to execute process");