[koenigdavidmj]

Most of this should be obviated when the ? operator is ready. But until then, there is no primitive for 'work on the type you wrapped in Option, short-circuiting and returning None at the first sign of failure', so it has to be done in the library.

[Animats]

If this is an accepted idiom, people will be using it for years to come. Sometimes only to be cool.

With "?" and "try!()", Rust is sort of emulating exceptions in a weird way.

[TeMPOraL]

I started using a similar idiom in Java 8 recently, inspired by Optional class and some new functions in Map interface. It took me an hour or three, but at some point I noticed that in few places I was writing like this just because it's "cool", even though it was less readable (and actually made it harder to use one code-navigation IDE extension I liked).

A lesson this strengthens in me again is that sometimes a cool-looking idea turns out to be pretty bad in practice, but you only figure it out after you go ahead with it. It isn't bad to try out things (that's how we learn), but you need to be extra honest with yourself about how the thing really feels when you're first using it, and never ignore that sense this new idea actually doesn't fit well and should be rejected.

[steveklabnik]

  >  Rust is sort of emulating exceptions in a weird way.

Except at the level Rust operates at, the code generation for exceptions vs. not is a thing. Not relying on landing pads, etc, is a thing people care about, and is why there's significant difference between return values vs exceptions can matter, even if at some higher semantic level, they're roughly equivalent.

[dan00]

I like it, because you get somehow the best of both worlds, on one side you're getting explicit error handling and on the other the convenience of exceptions, that you can just "raise" them and they propagate upwards in the calling stack.