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 (2 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

[–] Ephera@lemmy.ml 4 points 1 day ago (1 children)

Had to just think about why #[non_exhaustive] exists, so perhaps this helps you as well:

Imagine you're developing a really important core library, something like TCP. And then other libraries depend on your library.
Now, if you change your implementation, you may need to introduce a new error case, even though the rest of the API still works the same.

You have two choices to deal with that:

Release version 2.0, because that's a breaking change. Each library that depends on you needs to manually upgrade to version 2.0. Some never will, because they're unmaintained. Any application that ships your library as a transitive dependency will need to ship both, version 1.0 and version 2.0, for the next few years until the last of their direct dependencies has upgraded to 2.0 or been removed.
Or: You've declared that error enum #[non_exhaustive] before going 1.0 and therefore forced all depending libraries to implement a default match case. You can sneak in the new error case in version 1.1 without all those depending libraries needing to manually upgrade. The ecosystem does not split in half between 1.0 vs. 2.0.

Obviously, if it's a really egregious new error case that needs specific handling, then you might still want to release version 2.0, but by adding the #[non_exhaustive], you can decide later on and if you are such a central library, there's definitely going to be situations where you want to make use of it.

[–] sukhmel@programming.dev 2 points 1 day ago* (last edited 1 day ago)

I have been thinking of semver incorrectly, you're right: https://doc.rust-lang.org/cargo/reference/semver.html#enum-variant-new

[–] TehPers@beehaw.org 3 points 1 day 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.