Funny, I thought that when using `context(Raise<...>)` requires `suspend fun` since all side-e...

# arrow

[dave08]

Funny, I thought that when using context(Raise<...>) requires suspend fun since all side-effects should be suspend fun... am I wrong?

[dave08]

?

[CLOVIS]

Sorry, I replied to the wrong person.

[CLOVIS]

To answer your question: for technical reasons Effect doesn't need suspend anymore

[dave08]

So using Raise as a context by definition IS marking a side effect?

[CLOVIS]

That's how I understand it? You're declaring your side effects type-safely, so IMO it's fine

[Youssef Shoaib [MOD]]

It's not a side effect I believe. It's because it's encapsulated perfectly by the outside block, and hence while the implementation of raise relies on exceptions (which are side effects), raise itself doesn't conceptually result in a side effect

[simon.vergauwen]

Indeed, the exception is a technical implementation detail and Raise itself can be considered pure in the type-system. Similar to how Either is pure, or rather referentially transparent.

We've experimented with a lot of different designs, and this is the only one that makes sense in Kotlin. TL;DR without exception you cannot interop with Kotlin Coroutines, and enforcing suspend poses a lot of limitations in the API without any real benefits. AFAIK one of the reasons why Kotlin Coroutines choose CancellationException was to not break try/finally. Scala is also adding a similar construct into the language as Raise with the similar semantics, rationale and implementation called Label.