Hacker News new | comments | show | ask | jobs | submit login

Rust n00b here (I read a lot about it but haven't written a line yet), but wouldn't `.orPanic('error message')` be a better name than `.expect('error message')`? The latter seems backwards.

It'd be or_panic, following conventions.

The idea is that I expect this to be Ok/Some, and if it's not, please use this error message.

I understand the intent, but usually the programmatic object is the subject of the sentence, the method is the verb and the parameter/argument is the grammatical object.

Here, the programmatic object is the grammatical object. That's what I meant by 'backwards'.

could_fail().or_panic_with('message') may be even better.

A lot of people don't seem to agree with me but I think even expect is too long of a name and terseness for commonly used names seems more important to me than reading like natural language.

I don't think terseness helps much here, isn't the actual error message gonna dwarf the name of the method it's passed to in almost all scenarios?

You shouldn't really be using expect much :)

It's true I use and see unwrap more.

That's not good either :|

unwrap should be confined to test and temporary code. It somewhat makes sense in example code, but expect is better for that.

There are sometimes cases when you very easily know that the unwrap will never fail and if it does something has gone very horribly wrong, in which case you might use it.

Libraries should keep usage of unwrap/expect to a minimum. Applications can be more liberal with it, but they should try to use expect or better error handling.

Not everyone perfectly follows this, sadly. But most do.

It's at least partly a matter of affordance. You could soft-deprecate .unwrap() and .expect() (emit warnings at compile time, it will be annoying but not fatal), and provide a new version of expect with a name that's more cumbersome to type (or_panic_with(...) isn't bad in that regard, but you could do even worse... or_panic_with_error_message(...) :-).

I don't neccesarily disagree. Names are hard :)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact