Great!

What about std::ops::Drop (http://doc.rust-lang.org/stable/std/ops/trait.Drop.html)? What would the compiler do with the return value of its drop method?

I'm talking about error handling, exceptions are an specialization of that. I understand the analogy, but keep in mind it doesn't have to be done by wrapping everything in a try!() - albeit that's more idiomatic for people used to exception handling mechanisms.

> "Exception mechanism" because what happens in a try!/Result is no different, in principle, from unwinding one stack frame. [...] How can you know, when you make a trait, whether the implementation might fail? The only sensible spec for any function you aren't implementing yourself is to return Result. Changing it later requires changing every caller.

Some of which can be considered advantages depending on your point of view. Changing all the callers might be interpreted as a feature: the compiler is able to state that your error handling is unsound, instead of the programmer having to do manual inspection of every single caller because the compiler won't be able to catch the inconsistencies.

Also, you miss the point of the trait declaration here: if you are implementing a trait you should indeed use Result<T,E>, unless you *want* the function not to return an error, in which case the implementor would have to fail!(). That's an *explicit* way to encode if errors should be handled or returned, in a compiler-checked way, which is far superior comparing to the guarantees of the exception mechanism in C++.

> This is exactly the sort of thing that is better automated in the language. Fear of the "exceptions" boogie man leads you straight into the arms of his much-worse cousin.

This is where we disagree. If you think using a C++ mindset, you'll think using the type system is a weaker alternative, but that's because C++ cannot express code the same way, at least not without a lot of boilerplate inplace. Rust can easily use the type system to assure your code is sound regarding error handling too, which is much more powerful and another great feature of the language.

> Since Rust lacks every one of the flaws that C++ inherits from C that make exception-safe programming difficult and hazardous, there is nothing to fear from exceptions. Make everything return a Result by default and you're halfway
> there. Make every function body implicitly a try! block and you're 90% there, painlessly. The rest is code you would be obliged to write anyway.

Maybe a static/checked exception mechanism would have some similar properties, but it would bring some additional issues too - and complexities.

I'd rather go to a monadic approach, still allowing the user to explicitly fail!() when it can't deal with the error in a sensible way. Falling back to exception approach à lá C++ would only create implicit holes in the soundness of the programs, which IMHO would be a major step back in the language.