5 ms·

I agree with your final point. Sadly Rust’s model for errors is tied to a specific implementation. That is, you must issue check instructions after every functi

I agree with your final point. Sadly Rust’s model for errors is tied to a specific implementation. That is, you must issue check instructions after every function call. In C++, errors are truly zero-cost: Exceptions only cause overheard when they happen. (Also in C++, different exception handling implementations are supported) Rust could do something like this but it would need syntactic support for something like “throw.” In this hypothetical world, on throw the compiler could generate code that does the unwinding and all that. When a normal value is returned, it would just return as normal. The function call ABI would be one such that functions that returned Result<T> and returned normally would be assumed to have succeeded. Actually Result<T> wouldn’t need to be a real type, just decoration at the syntax level.

Rusky 9y ago
> Exceptions only cause overheard when they happen. They only execute instructions when they happen... but they still inhibit the optimizer when they don't. Calls that may throw act like branches in the control flow graph. They also introduce more code bloat for their landing pads. > Rust’s model for errors is tied to a specific implementation. The Rust ABI is unspecified for a reason. We're currently seeing a lot of optimization around struct and enum layout; I'm not sure why this couldn't be applied to the calling convention without any extra syntax for "throw."
- kindfellow92 9y ago
  It’s not exactly tied to that implementation but because error sum types are runtime values, it’s not clear whether a statement like “return foo” should return a normal value or do stack unwinding.
- kindfellow92 9y ago
  > They only execute instructions when they happen... but they still inhibit the optimizer when they don't. Calls that may throw act like branches in the control flow graph. This is a fair point and elucidates the trade off being made. Perhaps this is the reason C++11 has the “nothrow” attribute.
smaddox 9y ago
How are exceptions in C++ any more zero-cost than Option or Result in Rust? There must still be a branch operation in the code that C++ generates, or it wouldn't be able to handle the exception.
- kindfellow92 9y ago
  In C++ there is at most only one compare (presumably at the spot where the exception was detected). In Rust there is a compare all the way up the stack after every function call site, and it is executed if an error happens or not.

Rusky 9y ago

> Exceptions only cause overheard when they happen. They only execute instructions when they happen... but they still inhibit the optimizer when they don't. Calls that may throw act like branches in the control flow graph. They also introduce more code bloat for their landing pads. > Rust’s model for errors is tied to a specific implementation. The Rust ABI is unspecified for a reason. We're currently seeing a lot of optimization around struct and enum layout; I'm not sure why this couldn't be applied to the calling convention without any extra syntax for "throw."

kindfellow92 9y ago
It’s not exactly tied to that implementation but because error sum types are runtime values, it’s not clear whether a statement like “return foo” should return a normal value or do stack unwinding.
kindfellow92 9y ago
> They only execute instructions when they happen... but they still inhibit the optimizer when they don't. Calls that may throw act like branches in the control flow graph. This is a fair point and elucidates the trade off being made. Perhaps this is the reason C++11 has the “nothrow” attribute.

smaddox 9y ago

How are exceptions in C++ any more zero-cost than Option or Result in Rust? There must still be a branch operation in the code that C++ generates, or it wouldn't be able to handle the exception.

kindfellow92 9y ago
In C++ there is at most only one compare (presumably at the spot where the exception was detected). In Rust there is a compare all the way up the stack after every function call site, and it is executed if an error happens or not.