You can mark an enum as non-exhaustive, which requires any `match`es outside the crate to have a default branch
Conversation
For errors that's pretty much always what you'd do anyway, since if consumers care about any of your error variants it's probably only only one or two
1
1
Depends on the context. Diesel has an error variant for "this query was expected to return 1 or more rows, but zero were returned" for example which is commonly handled. Really the point is more than if your consumers can recover from a specific case, don't take the choice away
1
1
4
Yeah, and that's roughly how the Error trait works in Rust actually. It's just not nearly as ergonomic as matching an enum
2
3
i had a great convo with a few months ago about how to match on trait objects like non exhaustive enums and how we might do derived “vtable impls” to let enums play as trait objects
i had several other much worse ideas about enum/trait obj equivalence too
2
1
6
yeah imo enums should be traits over their variant types and basically just "inline trait objects", and we should get the exact same treatment in reverse
3
2
9
Kind of going backwards to Scala’s encoding of enums (using sealed traits)?
I think it's a reasonable design choice. It allows for lower friction changing between open and closed polymorphism
1
4
Funnily enough, Scala 3 (Dotty) now has Rust inspired sugar over sealed traits: dotty.epfl.ch/docs/reference - they have GADTs too though which I would looove in Rust.
1
3
Show replies