Youssef Shoaib [MOD]
02/12/2025, 7:34 PMResult
the way that it is? There is a potentially more efficient encoding where you leave failures unboxed, leave most successes unboxed, and only box successes that happen to be throwable. In other words, having the internal encoding be a union of Throwable | (R - Throwable) | SuccessfulThrowable<R>
jw
02/12/2025, 7:38 PMYoussef Shoaib [MOD]
02/12/2025, 7:41 PMjw
02/12/2025, 7:46 PMSuccessfulThrowable
as the value if !is Throwable
Youssef Shoaib [MOD]
02/12/2025, 7:47 PMis Throwable
, which should be rare (assuming we make SuccessfulThrowable implement Throwable, maybe I should've clarified that)Youssef Shoaib [MOD]
02/12/2025, 7:48 PMjw
02/12/2025, 7:49 PMYoussef Shoaib [MOD]
02/12/2025, 7:53 PMprivate class SuccessThrowable(val value: Throwable): Throwable by error // methods won't be used anyways
fun getOrThrow(): R {
if (underlying !is Throwable) return underlying as R
if (underlying is SuccessfulThrowable) return underlying.value as R
throw underlying
}
fun <R> success(value: R) = Result<R>(if (value is Throwable) SuccessfulThrowable(value) else value)
fun failure(error: Throwable) = Result<Nothing>(error)
Oops I think I just answered my own question. You need an instance check for every creation of Result. Yeah that's not too nice. Not sure if this was explicitly the reason why, but that's a pretty significant downside if we're counting instruction calls