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
Result
ing errors from a sub-call to the caller as well as it's own errors (which may be very handy ifthrows
becomes strongly typed (which, withasync
/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!