[Pitch] Enum Composition

Yup, so initially I was thinking about enum composition in the sense where two enums each with two cases (one case from each matching one from the other) produce a three-case enum after running them through the operator. This was because I seem to find myself writing functions in classes that can:

  • Only error with a subset of the enum defined as the class's list of possible errors (so why force the caller to handle everything?)
  • Pass through Resulting errors from a sub-call to the caller as well as it's own errors (which may be very handy if throws becomes strongly typed (which, with async/await, might be on the table at some point?))

So, rather than having a specific error enum for every function (either to explicitly list all errors or literally defining Either<A, B>, Either<A, B, C> etc) it might be more intuitive to be able to group errors logically from the start and the combine them. I chose & over | as in my mind this new feature seemed to match how protocol composition works.

This thread does raise some very interesting ideas that would be good to explore more, however technically it does deviate from the initial pitch. Which isn't necessarily a bad thing, it's a good discussion!

I tend towards "(; Type1, Type2 ;)," i.e. like current tuples (including optional labels) except there are semicolons as part of the brackets. This way we wouldn't have to promote "|" from an identifier- to a keyword-class punctuator.

I think part of the problem of unions being continuously rejected is their non-disjointedness combined with method overloading and generics increasing the amount of ambiguity.
A possible workaround being considered in Rust are enum variants. Enums are tagged in Rust and the RFC follows the idea of combining the enum name (type name) plus the field (type tag) of the enum to a new single type or at least something which can be substituted into type position.

I'm not exactly aware about how further directions may look like, but enum compositions, i.e. using enum variant types from different enums, may also eligible with this or a subsequent proposal.