So basically their argument is that the missing piece is anonymous sum types. I tend to agree! It would be amazing to have that as a language feature, i.e. Result<(), FooError | BarError>. Unfortunately that is unlikely to arrive to the language for a loooong time... But I think I will definitely try out this library in the meantime.
this post was submitted on 07 Oct 2026
24 points (100.0% liked)
Rust
8317 readers
4 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 3 years ago
MODERATORS
A language feature is not needed because macros exist.
I would even argue that perhaps the most important role macros play is blocking adding endless language features ๐
Macros are often not very ergonomical to use compared to language features.
Also, why anonymous product types but not anonymous sum types? It seems kind of weird to me. Anonymous sum types can be just as useful as anonymous product types, as the blog post illustrates quite well I think.
The language wouldn't have lost much without tuples actually. But they do at least have direct pattern destructuring utility. Anonymous enums don't.
They also don't pose potential future awkwardness if/when variant types become a thing.
While I agree with you that anonymous sum types are useful, the language designers tend to avoid anything that might include a hidden cost (in this case either the size of the enum or cost of boxing). Something along those lines might end up in the language eventually, though.
Interesting. I'm surprised that it's possible to use tuples like that. Might try this.
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.
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
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.