> the inevitable

It's not inevitable in the slightest. Rust made a conscious effort to avoid exceptions for good reasons, and there's no reason to suspect that Rust will suddenly pivot on its heel in the opposite direction. Despite your attempts to paint this as a slippery slope, the unwinding-halting mechanisms are there to provide a safety net for people writing Rust libraries that expose C ABIs so that library code can fail gracefully without taking down the parent process.

  > the traditional exception model is simply the best one

Citation needed. :P The Rust community has long since embraced Result-based error handling; I don't hear calls for adding exceptions nearly as often as you seem to suspect. As to "inevitability", you'll be sad to learn that Rust plans on adding a mechanism that will enable applications to make panics impossible to catch, by disabling unwinding entirely and translating all panics to outright aborts (some argue that this should even be the default behavior of Rust code, but that won't happen any time soon). And considering that Mozilla disables exceptions entirely in Firefox, I see no reason they would pressure the Rust developers to add exceptions to Rust.

You seem to be taking Rust's approach to error handling far too personally. :P It is not Rust's position that exceptions are a blight that must be scoured from the face of the Earth. It is merely Rust's position that there are easier ways to achieve concise and composable error handling for its intended domain, given Rust's other features and safety mechanisms.

> Despite your attempts to paint this as a slippery slope

It is, though. I'm not[1][2] the only one who very much prefers the exceptional model of error handling. Once the ability to catch exceptions exists, people like me are going to write exceptional code.

[1] https://github.com/rust-lang/rfcs/pull/1236#issuecomment-127... [2] https://github.com/rust-lang/rfcs/pull/1236#issuecomment-128...

> > the traditional exception model is simply the best one

> Citation needed. :P

When Java, Python, C++, and Common Lisp all converge on the same thing, maybe that thing has something going for it. Part of my claim is subjective, but I've worked on systems that used everything from abort to error codes to tagged unions to exceptions for error reporting, and I've found the exceptional code by far the easiest to work with.

In exceptional code, I can write foo().bar().qux() even though foo, bar, and qux can all fail, and without any extra syntactic noise.

> by disabling unwinding entirely and translating all panics to outright aborts

I believe that's a mistake: it's a reprise of the -fno-exceptions debacle of the C++ world, where the ecosystem is fragmented due to fundamental disagreements on the correct error handling strategy. You'll get into a situation where some components rely on panics being hard aborts for correctness and other components rely on non-aborting panics for error handling.

> And considering that Mozilla disables exceptions entirely in Firefox, I see no reason they would pressure the Rust developers to add exceptions to Rust.

Rust is probably a fine Servo implementation language. Tellingly, Mozilla also uses an infallible memory allocator. I merely believe that Rust's design choices for allocation failure and error handling lead to it being a losing contender when compared to modern C++ for general-purpose systems programming.

  > Once the ability to catch exceptions exists, people like 
  > me are going to write exceptional code.

By all means, go ahead. :) Application code is free to do whatever it wants, and godspeed to you. Meanwhile, the restrictions on the catch API will be sufficiently onerous that library authors will continue to favor Result-based error-handling for their public APIs (to say nothing of the fact that some of their users may have opted to turn panics into aborts).

  > You'll get into a situation where some components rely on panics 
  > being hard aborts for correctness and other components rely on 
  > non-aborting panics for error handling.

Indeed, this is precisely why Rust decided to ship 1.0 with unwinding enabled by default, much to the consternation of those who wished unwinding to be excised from the language entirely. The language is defined such that if your personal `unsafe` blocks fail to consider exception safety, you run the risk of undefined behavior and thereby forfeit Rust's guaranteed safety mechanisms: http://doc.rust-lang.org/nightly/nomicon/exception-safety.ht... . Meanwhile, the fact that catching unwinding is all but unusable as anything other than a failsafe of last resort (and even then is only intended to prevent a total abort and/or undefined behavior) means that no library is going to resort to non-aborting panics for error handling, as mentioned previously.

> library authors will continue to favor Result-based error-handling for their public APIs

Except for the library authors who opt to write in C++ instead, of course. If you have to deliberately make a feature of your environment difficult to use, you're optimizing for the wrong thing. The Java experience shows that bad programmers will write bad code no matter how many safeguards you try to add to the language, so the only worthwhile "speed bumps" are those that help people who know what they're doing not accidentally shoot themselves in the foot. I cannot imagine an exception-catch block appearing in my code by accident.

Quite a bit of the discussion in the threads you mentioned has to do with flagging code as "requiring review" and adding "speed bumps" for "potentially troublesome" code. That's very worrisome, as it indicates that at least some members of the Rust community favor the Java-esque sandbox model of safety over the safety-catch model.

C++ has many flaws, but at least it never makes me feel like the language designers thought I need to be protected from myself.

  > the only worthwhile "speed bumps" are those that help 
  > people who know what they're doing not accidentally 
  > shoot themselves in the foot. I cannot imagine an 
  > exception-catch block appearing in my code by accident.

Rust is very much designed to help people who know what they're doing not shoot themselves in the foot. The risk isn't in a catch block appearing in your program by accident, it's the fact that exception safety is an invisible footgun that has potentially severe implications even for code that doesn't believe that it has any reason to concern itself with error handling in the slightest.

(The irony in all this is that Rust's approach can be interpreted as an attempt to return exceptions to their roots by relegating unwinding to exceptional circumstances, as opposed to the routine error-handling solution that they've become in languages that have chosen to embrace exceptions (e.g. Python's egregious `StopIteration` exception for loop termination).)

> return exceptions to their roots by relegating them to exceptional circumstances

Python does it right. I've never bought the argument that "exceptions are for exceptional circumstances". If you use error codes for some errors and exceptions for others, all you do is confuse people. The definition of "exceptional error" is subjective, after all.

As far as I can tell, the advice to use "exceptions for exceptional circumstances" originated in C++ circles in the 1990s, when support for exceptions was bad and throws were slow. The thinking was that you could efficiently use error codes for commonly-encountered errors and still get some of the syntactic benefits of using exceptions for rarer errors. Also, if you were using a compiler without exceptions support, you could turn your exceptions into aborts while not aborting just because a file doesn't exist. You can see vestiges of this thinking in the iostreams API.

Somehow, this performance hack morphed into commonly-accepted dogma. I don't accept this dogma. Exceptions are for any situation that a function can't meet its contract. In Python, if an iterator can't supply its next element, it can't satisfy the contract, and the exception tells you why. I don't think there's anything particularly wrong with that.

I suppose we'll have to agree to disagree, then. :)