A modern programming language that makes developers happier.

kotlinlang

Does anyone has insights in the “Rich errors” feature that was announced? It looked similar to what `Either` does, didn’t it?

I believe they said experimental in `2.4`  so probably in a year or so

Yes, it’s a long time before we can use anything

I’m hoping it will let us use union error types even with Arrow, as I prefer the Arrow DSL. Do you think it might end up working?

It looked like the pattern was `fun somWork(): SuccessReturnType | FailureReturnType { ... }` I wonder if the `|` operator is a shortcut to some sort of new `Result` type. Then arrow could create some extension types for whatever `|` will give to the developers

*This is all speculation based on my impressions from the conference*, but I think there's no inherent order to the types, just that they are meant to be different categories.. so if I have something like:
```error class TransactionError
error class UserError```
then a function might in theory return `fun withdrawMoney(): TransactionId | UserError | TransactionError`

If we instead stick with `Either`, then we could have `Either&lt;UserError | TransactionError, TransactionId&gt;`  which would let us handle only the relevant error types without needing to have a common supertype for those two errors. This would be really neat for error handling IMO, since we get to keep the left/right semantics, with "raise returns", folds etc.

The design is not finalised so it’s hard to say right now but it will either be a full blown replacement and we either soft deprecate it with a clear migration path (if that’s what the Arrow community wants), or we offer a nice integration between them where you can move back -and forth.

i imagine with the limitation of error types needing to be final so you cant make sealed hierarchies of errors there's still some use for an Either type that doesnt have that limitation, although the union typealias approach for expressing multiple possible error will probably cover enough of the use cases for a sealed error type that it isnt worth having two different constructs for very similar ideas

Either is still definitely useful, just like how Option is useful in face of `null` existing, because it allows arbitrary nesting of itself inside itself, which is useful in some scenarios. I suspect what we may do is make `Either.Left` an `error data class`, and then provide functions that return `A | Either.Left`, while still preserving functions that don't.

This all feels like speculation until the design is final to be honest. Most importantly we'll have to think about binary compatibility, and not breaking dependent projects. Secondly, we'll have to think what is best for the (Arrow) community and we'll have to do some surveys, and polls. If any transition or deprecations take place it'll probably be a 2-3 year process before we'd eventually move to 3.x, and even though we might still provide a "fallback" module for those users that cannot migrate or do not want to migrate.