Hello everyone :wave::skin-tone-4: with my team we...

# language-evolution

[max.cruz]

Hello everyone 👋🏽 with my team we were evaluating do some changes and base our error handling in the new Result class. I was taking a look at the fold implementation and I realize that the usual order from other languages and libraries is inverted, instead of left for errors and right for success is the other way. I was wondering and getting curious if this has some specific reason? Thanks in advance

public inline fun <R, T> Result<T>.fold(
    onSuccess: (value: T) -> R,
    onFailure: (exception: Throwable) -> R
): R

[ilya.gorbunov]

That's why we call the possible outcomes of Result "success" and "failure" rather than "right" and "left" — to avoid the unnatural order they impose on the fold method parameters.

[Ky Leggiero]

Yeah it is weird. You should handle your errors before you assume it succeed; it's psychologically better that way

[Joffrey]

@Ky Leggiero I’m not sure about that. Compare:

try {
   // doing successful code
} catch {
   // handling failure
}

To:

result.fold({
   // doing successful code
}, {
   // handling failure
})

Seems pretty convenient to me.

[max.cruz]

It’s thinking in the try/catch pattern, but thinking in functional patterns it isn’t so natural. Well, Result looks like the Try or Either type in some functional languages, and by convention for error handling, the Left represents the error case, whereas the Right contains the success value, that order is also in the fold function