Revise Result type for Kotlin 1.5, remove restrictions

[elizarov]

• Kotlin 1.5
  • Allow returning the Result type from functions.
  • Allow Kotlin null-safety operators ?., ?: and !! on both nullable and non-null Result types.
  • Text updated to replace inline class with @JvmInline value class.

[ilya-g]

+1 to @udalov suggestions.

[arhont375]

Just read this KEEP as updated in this PR and there still places where:

1. Said that However, writing functions that return Result is not allowed in Kotlin in the Appendix seciton.
2. sealed inline class used in the future improvements section, should it be sealed value class?

I'm not sure if it's intended or not, but such inconsistency confused me during read

[elizarov]

@arhont375

1. Said that However, writing functions that return Result is not allowed in Kotlin in the Appendix seciton.
2. sealed inline class used in the future improvements section, should it be sealed value class?

Good catch. Thanks. Fixed.

[LouisCAD]

runCatching would catch any Throwable, including CancellationException, which becomes a problem when your code rely on them to be thrown to be cancellable.

To alleviate that significant problem, I'm suggesting to make the lambda of all the runCatching functions crossinline, so one cannot run suspending, and likely cancellable code into a construct that would eat what powers the cancellation mechanism.

That safety measure would limit usage of runCatching, but with the benefit of making it impossible to misuse, ans encouraging people to define their own, domain specific error types, until possible new facilities come into the language or libraries to make it less effort to implement.

[ilmirus]

@LouisCAD fixing runCatching does not fix other problems with CancellationException. To fix the issue, we should make structured concurrency a language feature instead of library one. I.e. treat cancellation as we treat suspension. We do not have SuspendedException, after all.

[LouisCAD]

Sure @ilmirus , but in the meantime, it'd avoid a lot of bugs, and that crossinline can always be dropped later without affecting anyone.

Is structured concurrency as a language feature something we can expect in the not too distant future?

[gmk57]

runCatching would catch any Throwable, including CancellationException, which becomes a problem when your code rely on them to be thrown to be cancellable.

To alleviate that significant problem, I'm suggesting to make the lambda of all the runCatching functions crossinline, so one cannot run suspending, and likely cancellable code into a construct that would eat what powers the cancellation mechanism.

I've hit this too, but current behavior makes sense if you regard runCatching just as a fancy try/catch.

Personally, I often use runCatching as a top-level wrapper around a whole bunch of suspendable work. There is no heavy lifting after it, so non-propagating cancellation is not a real issue. Making lambda crossinline would break this use case.

Now that Result is non-restricted we can freely make our own variants of myRunCatching, e.g. with
if (e is CancellationException) throw e

And in some (rare) cases it is preferrable to treat CancellationException exactly like any other exception, e.g. in some Repository:
.onFailure { dataLoading = false }

[camhashemi]

is there a discussion or proposal we can link to for why these restrictions were lifted?

I've just been catching up on the original keep and discussion, but I don't see anything around this restriction being removed. So there's a gap for me between "Result is only allowed for restricted use cases" and "Result is only encouraged for restricted use cases".

[elizarov]

@camhashemi is there a discussion or proposal we can link to for why these restrictions were lifted?

The original keep mentioned some potential future enhancements to support null-related operators like ?. and ?: to have a special effect for result types. We've tried to design this approach in more detail and did not find any feasible way forward. With this potential enhancement off the table, there was no need to restrict usages of the result type anymore.