[jffaufwwasd]

This is where you should be combining them.

Ok' and Err' as nominal type constructors which are unioned:

    struct Ok<T>(T);
    struct Err<E>(E);

    fn parse_error(input_string: &str) -> Ok Error | Err (ErrorA | ErrorB | ErrorC...)

Or make a sum type

    enum Result<T, E>  {
        Ok(T),
        Err(E),
    }

    fn parse_error(input_string: &str) -> Result<Error, (ErrorA | ErrorB | ErrorC...)>

The error types are unioned for easy composition but you have a top level sum type to differentiate between success and failure.

[amluto]

Ah, so you want both sum and union types, and you probably want those unions to be genuinely unordered, so that A | B is the same as B | A. And maybe even with inferred subtype relationships or automatic conversions so that A | B can be used where A | B | C is expected. This could be useful.

I can also imagine it resulting in horrible compilation times and/or generated code bloat in a language+toolchain like Rust that insists on monomorphizing everything.

[anon-3988]

This is brilliant, I feel like Rust should ultimately arrive at this but imagine this is very hard to implement from the tooling perspective.