You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea is to provide some way for recover, when called within a Raise, to reuse that Raise object not only for performance reasons, but also by re-exposing all the APIs that the original Raise had. This would theoretically work by capturing the CE like what fold does, with perhaps some mechanism to access the underlying Raise instance that a custom Raise implementation is using.
This has the issue, however, that leaks won't be detectable if they happen within a recover, and then they're invoked before the outer raise finishes. For example:
either<Int, Int> {
lateinit var f: (String) -> Nothing
recover({ f = { raise(it) } }) {}
f("foo")
}
Currently, this gets detected as a leak, but I can't imagine a way for that to work if the Raise gets reused.
The text was updated successfully, but these errors were encountered:
I experimented a little with this, and I'm quite sure that this isn't possible. It comes down to the idea that any 2 Raise instances that we have in scope could actually be the same ones. This is due to Raise being declared as in. Even if it was invariant, the reusing mechanism would thus have to be invariant and hence wouldn't be very helpful.
Consider this code:
either<Any, Unit> {
foo()
}
context(Raise<Int>, Raise<String>)
fun foo() = recover<Int, _>({
raise("bar")
} { error: Int ->
// CCE if we're reusing raise instances
}
Note also that re-exposing APIs is unnecessary when we get context receivers. Any "performance" that could be gotten out of this is surpassed by the runtime errors it would cause.
Related to #3126 and #3052.
The idea is to provide some way for
recover
, when called within aRaise
, to reuse thatRaise
object not only for performance reasons, but also by re-exposing all the APIs that the originalRaise
had. This would theoretically work by capturing the CE like what fold does, with perhaps some mechanism to access the underlyingRaise
instance that a customRaise
implementation is using.This has the issue, however, that leaks won't be detectable if they happen within a
recover
, and then they're invoked before the outerraise
finishes. For example:Currently, this gets detected as a leak, but I can't imagine a way for that to work if the
Raise
gets reused.The text was updated successfully, but these errors were encountered: