> I often find myself wishing the nim standard library used results instead of > exceptions (this is extra painful with async code because the stack traces > are a nightmare to understand).
fwiw, we've rewritten large parts of stdlib to do exactly this - <https://github.com/status-im/nim-stew> is a starting point for that work, but you'll find more in many of the libraries here: <https://github.com/status-im/nimbus-eth2/tree/unstable/vendor> Works great, we're not looking back and we'd love to see more of such libraries ;) For `async`, we're in the process of doing that too, via the new `raises` enforcement in [chronos v4](https://status-im.github.io/nim-chronos/error_handling.html#checked-exceptions). Broadly, for most of our use cases, this proposal would not move the needle - we often need to transport more information to the caller related to the error (like a compiler needs to return line number where the error happened) - there exist workarounds (like TLS etc) but they tend to come with their own downsides. For `Result` to become both natural and efficient, two things are missing: sum types (this is exactly the same as a case object / variant with exactly one `case`) and pattern matching over them - this would allow a compiler to generate optimal code similar to this proposal (it would obviously not address the desire for centralised error code management where everyone's supposed to use the same thing).
