Alternative implementation for kotlin's Result typ...

# stdlib

[Youssef Shoaib [MOD]]

Alternative implementation for kotlin's Result type:
Instead of boxing every Throwable inside of a Failure class, why not box every Result.success that happens to be a Throwable into some SuccessThrowable class, and thus non-Throwable success values and exception values can both stay unboxed. I expect that Throwable success values would be very rare, and thus this would rarely, if ever, cause issues. This kinda falls out of comparing Result<S> with an untagged union type S | Throwable and noticing that to make this a tagged union, it only suffices to differentiate S values that also happen to be Throwable.
Is there an issue with this design?

[ephemient]

technically sounds like it would work, but it's a binary incompatible change, and exceptions are supposed to be rare anyway, is the complexity worth it?

[Zach Klippenstein (he/him) [MOD]]

Can't speak for JB, but here's my thoughts:
1. It would increase the complexity of the whole thing significantly, because now you'd have 2 separate places where logic branches: Success vs Failure, and Success (Exception) vs Success (Non-exception). Right now there's only Success vs Failure, and within both of those branches there's no special cases. Simpler is usually better.
2. I believe the reason for boxing exceptions is partially performance-related: throwing exceptions is more expensive than non-exceptional control flow, so the overhead of boxing isn't as big a deal if you're already paying the cost to throw in the first place. If you're passing exceptions around as successes, then you probably want to keep the same performance characteristics as for other successes.