<@U12AGS8JG> you can always call the function like...

# arrow

[raulraja]

@sam you can always call the function like that inside suspend we may even lift that restriction in fx down the road but in whatever case the biz about getting rid of Either is that IO is gonna be soon IO<E, A> so you don't need Either because you can do just(a) or raiseError(e) and that is the same as Either. You can also do raiseError(exception).

[Derek Berner]

I get the business of Try going away, but I'll point out I'm not super happy about Either going away. There are other reasons to use tagged unions besides error conditions

[Derek Berner]

Where for example you might not want to use a sealed class.

[Derek Berner]

You also don't have Coproduct2 because you already have Either

[Derek Berner]

IO represents a program while Either represents a tagged union type - one is not a drop-in for the other

[Derek Berner]

Even elm with all its ruthless treatment of redundancy recognized a need for both Task x a and Result x a

[sam]

It's also just easier to explain an Either

[sam]

since in English it is what it is

[Derek Berner]

For that matter, what about renaming IO to Task?

[Derek Berner]

That's essentially what an IO represents - something "to be done"

[Derek Berner]

As a concrete example, I might get an Either<Long,Customer> from a JSON RPC call - the left hand case indicating that a database lookup is required.

[sam]

Sometimes i do date parsing and return Either<Duration, Period>

[Derek Berner]

Or I might want to hand an Either<RPCError, Customer> off to Kotlinx Serialization

[Derek Berner]

I could compose IO using handleErrorWith but that seems like taking the long way

[raulraja]

Either is not going away

[raulraja]

What we mean is that if you are using today suspend() -> Either<E, A> then you can replace it with IO<E, A>

[raulraja]

but Either is staying

[raulraja]

it's just not a data type to suspend effects or deal with effects in any way as it's only purpose is to denote a disjunction of types

[raulraja]

The only data type that is gonna be removed related to all this is Try because it can't suspend side effect

[sam]

I love Try, I like doing Try { ... }

[raulraja]

but you can't do Try { suspendedFunction() } unless you are in suspend right?

[raulraja]

that is the issue with many users, the same for IO works because it has a way to handle suspend, Try doesn't so it only helps you with third party libs and custom functions that do not use suspend for effects

[raulraja]

IO { suspendedFunction() } that works and handles errors

[raulraja]

also can survive async. Try would be broken if anyone uses delay inside suspension because it has no way to suspend the coroutine

[raulraja]

So for Try to stay it has to implement a suspension runtime which is what IO does.

[raulraja]

Now if Try does that there is an issue. Try is eager which means that safe resource acquisition is not possible

[raulraja]

Current Coroutines Core can't implement safe resource acquisition if the aquisition phase happens in an async job because anyone can cancel the eager coroutine

[raulraja]

IO has solved this issues with suspension and Try is becoming more irrelevant as everyone in Kotlin is moving to suspend.
Coroutines Core is also encouraging that everyone in Kotlin should use suspend and currenty Try can't do any of it

[sam]

Ok that makes sense

[sam]

can't the lambda to try be marked as suspend ?

[sam]

so it's only usable from suspend itself ?

[raulraja]

Not the lambda but the actual Try invoke should be a smart constructor in the companion that it's flagged as suspend

[raulraja]

So it can only be constructed inside suspend

[raulraja]

Then we can keep Try since it's just a utility that can only be used in suspend which already guarantees try eagerness won't fire too early

[raulraja]

Would that work for you @sam?

[sam]

Sounds good

[kioba]

IO or not IO, there is no Try