[steveklabnik]

This is an area where you just can't actually please everyone. I have heard the same opinions you've expressed in this thread, just as strongly, for even including unwinding at all. That aborts should be the only option, and that the cost of unwinding is far too high to be included in a true systems language.

Language design is tough. I'm glad we have multiple languages.

[quotemstr]

It's _because_ Rust tried to please everyone that it painted itself into this corner. If the exception people had won, life would have been great.

But if the error-code people had won, then life would still be good, because then Rust's stdlib might have been a bit uglier, but it would at least be correct with respect to error propagation. It's because Rust tries to satisfy both camps --- because it tries to give you the concision of exception code and, er, the lack of actual exceptions --- that it's forced into the terrible position of needing to abort internally on error, lacking a way to report errors to higher level code.

The lesson here is that optimizing for happiness and harmony leads to bad design.

[steveklabnik]

I prefer "taking all use-cases seriously instead of abandoning a segment of users" to "happiness and harmony," as a characterization here. If serious use cases were not presented for both options, we would have enforced one. Or, if Rus weren't a systems language, we could have enforced one.

At the end of the day, if you have exceptions, you can still call abort in your exception handlers, so the split exists regardless. And without first-class support, those users are paying for a feature that they aren't using, which is against a core value of Rust.

[nwmcsween]

You are arguing for replacing bad behavior "abort on OOM" with something even worse, exceptions. I honestly don't think you know what exceptions entail wrt what compilers do and the resulting bloat.

[quotemstr]

What, unwind tables? The ones that go untouched in normal operation? They're hardly catastrophic, and you need unwind support as a mandatory part of some ABIs in the first place. I know perfectly well what exceptions entail, and I maintain they're vastly better than other error handling strategies. You're the one who doesn't know what he's talking about.

[nwmcsween]

You do understand it's usually in the ballpark of +20% or more to text or so that is in the loaded part of the program right? Also define mandatory, what requires eh_frame..?

[quotemstr]

The Windows 64-bit ABI, for starters. The world is not Unix. As for additional text: compare that with the code spent on explicit checks of error values. You can't just enable exceptions on an existing codebase and point to how awful they are without account for the now-extraneous code that exception support allows you to remove.

[nwmcsween]

the x86_64 psabi also requires eh_frame but it's actually not used for much except exceptions, stack unwinding, etc thus is mostly useless. Of course all of this is sort of moot with rust as rust requires eh_frame.. and the resulting bloat.