> It's a pretty sweet design
Yeah, it is, but it wouldn't interact well with Rust's safety guarantees :)
(You're analysing this feature in a vacuum, but that's not how language design is done.)
> Easy to read code with standard control constructs.
I think this is in the eye of the beholder, `try!` or `?` or `catch` are (would be -- for the latter two) easy to read for Rust folks. It's just different. do-notation in Haskell is similarly "standard" for functional types, but it's totally alien to C++ folks. The main reason folks find try/catch/throw easier to understand is because they're used to it. Once I learned how enums worked in Rust, `Result` was a very straightforward and simple thing. I actually personally find `try!` easier to read, since I know exactly where a return can happen, unlike C++ where the control flow is totally obscured.
This leads to the rug getting pulled out from underneath you, which can be bad for safety. In fact, Rust's `recover()` needs to be careful about types allowed to cross a recover boundary so that it can be 100% memory safe.
So the code might be easy to read, but not easy to reason about.
> No dispatching on error types, therefore less temptation to use errors for control flow.
I don't get what you mean here. Rust doesn't dispatch on error types, though it does dispatch on Result (which may contain an error). I don't see what's wrong with this. This lets you program in a functional way (and like I mentioned, you don't have to), which isn't a bad thing.
Errors _are_ a control flow thing, you can't escape that. C++ handles the control flow around errors with try, throw, and catch, Rust does it with Result and its methods (and the try macro).
> especially if you need to catch errors from code you don't control.
`recover()` exists. Use it sparingly; it's basically only for cases when you want to catch panics in code you don't control (even then, try other solutions), or stop panics from crossing FFI boundaries.
Panics are supposed to be for irrecoverable or impossible things, where "irrecoverable" is usually a statement that only makes sense in an application, not a library. So this problem in theory shouldn't come up (I haven't seen it happen much in practice).
I think the problem of forgetting to catch an exception from code you don't control because you don't know it's there is a much more pressing problem than having stray panics (since panics are relatively rare).
> No distinction between code that can cause errors and code that cannot, thus higher-order functions become easier to write.
Result is also a type. Treat it as any other return type in a higher order function and it works. In `Fn(...) -> T`, `T` can be a Result type, no problem.
> Rust can't even claim to be transparently callable from languages that don't support exceptions, because panics exist
and so does `recover()`.
> No performance overhead in the common case.
IIRC it doesn't turn out to be much, but ICBW. I think someone looked into this.