I don't think this was the argument being made. To me, the point was that an unbiased
Either type is a bad choice to use in place of a
Result type because, well, it is unbiased. This means that people have to arbitrarily choose whether the generic arguments are ordered
<Success, Failure> or
<Failure, Success>, leading rise to inconsistency (will there be style guide advice on how to order them?), confusion (e.g. if the result is
Either<Int, String> is that an integer result and a string describing the error or an error code and a string result?), poor naming of enum cases and methods (e.g.
mapLeft(…), etc). You can fix some of this with a
Result typealias, in either your own code or the standard library, but that doesn't fix the poor names for generic parameters, enum cases and methods.
Either type is desirable in the standard library, I would strongly argue for it to be a separate type from
Result with its own great names and methods, rather than mashing the two together because they're structurally similar.