4 ms·

> At the limit limit, there is no difference between Result<T,E> and checked exceptions How do you figure? A Result<T,E> always means a branch after function c

> At the limit limit, there is no difference between Result<T,E> and checked exceptions How do you figure? A Result<T,E> always means a branch after function calls, while checked exceptions have no such cost. Toy example: https://godbolt.org/z/Gqo9n17c6 https://godbolt.org/z/Gqo9n17c6 It's trivially observed that exceptions simply have less code in the normal path. There's no post-call checking for errors, which is of course present in the Result<T,E> approach. And even where the exception is caught, that's not part of the "hot loop". It's not executed at all normally. Unwinding exceptions are completely free when they don't happen. The same is simply not true and never can be true of a return-value based propagation.

gpderetta 2y ago
See my other comment.
saurik 2y ago
"At the limit limit," you can detect the unstructured branches littered through the codebase of people using Result and convert it all into clean structured exceptions, and even automatically remove all the boilerplate this paradigm uses to propagate errors; this is at least a reasonable thought process due to the same reason you can (much more trivially) implement your exception mechanism by burning a return register for an error code and compiling in a ton of branches (which isn't insane if you in fact want to throw an error often: this is all just a tradeoff that Rust made awkward and its community turned into a religious war). It isn't easy, though, as the Rust way of doing this--letting people pass around a bare Result without the structure of a monad (which is why Haskell's version of this idea looks like exceptions, and why it is so frustrating when people incorrectly claim Rust has "monadic" error handling)--makes it extremely easy to pull off what should be "stunts", such as holding onto a Result and trying to resolve them in an irreducible order; but, "hopefully", most code isn't making that mistake (and you can still implement it by adding a spurious expensive catch in just the places they did that)... but like, that's why I think the person you are responding to might have said "at the limit limit", to really emphasize that this is a pretty complicated reduction to automatically apply globally and truly result in 0 cost.

gpderetta 2y ago

See my other comment.

saurik 2y ago

"At the limit limit," you can detect the unstructured branches littered through the codebase of people using Result and convert it all into clean structured exceptions, and even automatically remove all the boilerplate this paradigm uses to propagate errors; this is at least a reasonable thought process due to the same reason you can (much more trivially) implement your exception mechanism by burning a return register for an error code and compiling in a ton of branches (which isn't insane if you in fact want to throw an error often: this is all just a tradeoff that Rust made awkward and its community turned into a religious war). It isn't easy, though, as the Rust way of doing this--letting people pass around a bare Result without the structure of a monad (which is why Haskell's version of this idea looks like exceptions, and why it is so frustrating when people incorrectly claim Rust has "monadic" error handling)--makes it extremely easy to pull off what should be "stunts", such as holding onto a Result and trying to resolve them in an irreducible order; but, "hopefully", most code isn't making that mistake (and you can still implement it by adding a spurious expensive catch in just the places they did that)... but like, that's why I think the person you are responding to might have said "at the limit limit", to really emphasize that this is a pretty complicated reduction to automatically apply globally and truly result in 0 cost.