Code that doesn't return Result will have no runtime cost added just like code that doesn't have a throw statement doesn't. Code that returns Result but is alw

Code that doesn't return Result will have no runtime cost added just like code that doesn't have a throw statement doesn't. Code that returns Result but is always Ok will have a very small overhead just like code that can't provably never throw will. But I'd wager it's extremely small given that on modern CPUs branches never taken are much cheaper than they were in 1990. To put it in more plain terms, the reason that C++ exceptions have "no overhead" when an exception occurs is that the exception handler code will only be dispatched when an exception is raised. The same is true of error handlers in Rust. No Err, no handler called. The difference is the branch is always there. So the question in 2022 is, how expensive is a branch that is never reached? Today it is basically nil, depending on your hardware. Branch predictors are pretty good and pretty ubiquitous (nb4 someone comes talking about how this wouldn't work on their Blackfin ADSP or whatever - neither will exceptions!). There is a small overhead though in that there are two branches. The other nuance is stack unwinding. But in practice this is generally a good thing in debug builds that you can disable in release if you want to. At the end of the day, the practice is for users not to write or call code that may error or propagate errors when the utmost performance is required. Inputs get validated up front and fail fast so the hot loops maximize performance.