I like the general idea (not a fan of the syntax but whatever). The one thing I'm not seeing is non-exhaustive error types. For example, in a library, you likely want to say "these errors are known to be possible, and some errors may be added in the future". Without non-exhaustive error types, this would mostly be useful exclusively in applications, not libraries. Of course, syntax-wise, you can just do (E1, E2, ...) or something to mark it non-exhaustive (if you were to add this to the language directly).

Either way, I agree that defining errors is needlessly extraordinarily verbose. ~~I'm tempted to make a simple one-line macro to union a bunch of error types into an enum.~~ (or use this library since I misread this as a language proposal lol) This, of course, falls apart when a function might use the same error type for multiple errors, or if it uses custom errors with no inner errors, but those cases are what thiserror is for.

[–] sukhmel@programming.dev 1 points 2 days ago (1 children)

I'm not sure non-exhsustive makes sense — you want the caller to handle everything you may return to them, and the new errors won't be handled. Maybe a default branch in the handler could do, though

[–] TehPers@beehaw.org 3 points 2 days ago

Maybe a default branch in the handler could do, though

This is exactly what it's for. #[non_exhaustive] forces you to add a default branch when matching on the error. It's already used a lot, so without a way to do that, it becomes less useful in library code.