Result 2.0: unsafe unwrapping of `Result.value` and `Result.error`

[kirillzh]

I noticed that the new inline value class in API 2.0 lets us access result.value directly without checking if it’s actually safe, which wasn’t the case before. Here’s what I mean:

val result: Result<Int, SomeError> = getResult()
result.value // This compiles even if the result is an error, leading to potential runtime errors.

This could lead to runtime exceptions that were harder to make before when the API required type checking and more explicit unwrapping using getOrThrow() (which is a lot easier to catch or denylist through code analysis).

It seems like API 2.0 introduces a downgrade in compile-time safety compared to the previous version. Could we consider reinstating some form of safety, perhaps through Kotlin contracts or another mechanism, to prevent potential runtime errors?

[michaelbull]

Could we consider reinstating some form of this safety, perhaps through Kotlin contracts or another mechanism, to prevent potential runtime errors?

Do you have a proposal of which compiler contract would achieve this? We effectively need user-defined guards, such that you can't call .value unless you've done an isOk/isErr check - I don't think such a thing exists in Kotlin?

[raamcosta]

If value is always available, then maybe it should be nullable. This way we can check if it is null, and get smart cast.

It would also mean that people are more likely to use better approaches such as doing .onSuccess { value -> } given that inside the lambda, "value" wouldn't be null.

But I may be missing something?

[michaelbull]

It being nullable would force it to be boxed at all call sites. See the following example from Kotlin's docs:

interface I

@JvmInline
value class Foo(val i: Int) : I

fun asNullable(i: Foo?) {}

fun main() {
    val f = Foo(42)

    asNullable(f)  // boxed: used as Foo?, which is different from Foo
}

https://kotlinlang.org/docs/inline-classes.html#representation

[raamcosta]

For us at work, in the type of apps I develop, I’d rather have safer compile time access than the optimisations. So this means we’ll keep using version 1 then.

I guess it would be interesting to know how much users of the library fall into the same camp as us.

Also, I’m not sure if version 1 would need to have some support going forward? With updates to Kotlin versions and stuff like that? Probably not new features though.

[kirillzh]

For us at work, in the type of apps I develop, I’d rather have safer compile time access than the optimisations. So this means we’ll keep using version 1 then.

I guess it would be interesting to know how much users of the library fall into the same camp as us.

Also, I’m not sure if version 1 would need to have some support going forward? With updates to Kotlin versions and stuff like that? Probably not new features though.

Sharing the sentiment here. We didn't get a chance to prioritize this but we will likely either downgrade to version 1, or fork/implement our own Result type.

I'm a bit disappointed to see this issue being closed without resolution, considering that this API change is a quite major regression (loosing compile time safety), in my opinion.

[michaelbull]

@raamcosta

For us at work, in the type of apps I develop, I’d rather have safer compile time access than the optimisations. So this means we’ll keep using version 1 then.

I don't think it's necessarily any different. In v1 you have .unwrap() which unsafely gets you the value, in v2 you have .value which unsafely gets you the value. In neither case does the compiler help you, it's just the difference of a function call vs a property accessor.

Also, I’m not sure if version 1 would need to have some support going forward? With updates to Kotlin versions and stuff like that? Probably not new features though.

I am not maintaining two versions going forward.

[michaelbull]

@kirillzh

Sharing the sentiment here.

As mentioned above, it's really no different. You always had access to unsafely getting the underlying value (by calling .unwrap()), you just don't do it with a function call now.

We didn't get a chance to prioritize this but we will likely either downgrade to version 1, or fork/implement our own Result type.

I'm a bit disappointed to see this issue being closed without resolution, considering that this API change is a quite major regression (loosing compile time safety), in my opinion.

The issue has been open for over half a year and no active discussion is happening.

As it stands you have still not replied to my message engaging with you, so to come back and express disappointment is rather rude. If this is a priority to solve I would appreciate at minimum an actual reply to messages I post in the thread.

A reply to the questions I've asked would be better than coming back after 6 months to express your disappointment with my project management.

I have asked and engaged on this subject and the conversation came to a complete halt with no solutions or improvements being proposed. If you have something that would change that, then a PR is welcome.

[kirillzh]

As mentioned above, it's really no different. You always had access to unsafely getting the underlying value (by calling .unwrap()), you just don't do it with a function call now.

@michaelbull I should have clarified - in our codebase we disallowed usage of unwrap() (a common practice in our Rust counterpart too), and instead we relied on compile time safe type checking, before:

val result: Result<Int> = ...
// result.value is not possible to call until type is checked - good!:
when (result) {
  is Ok -> result.value
  is Err -> ...

Now, I can just call result.value without checking for "type" and risk it throwing an exception at runtime.

[michaelbull]

I should have clarified - in our codebase we disallow usage of unwrap()

How did you disallow it? Can you disallow calling value the same way?

You really want the value/error accessible only in functions that have Result as a receiver, as they are likely to be the library functions that require it, which would stop accidental unwrapping in business logic.

If you can shed some light as to how you managed to arbitrarily stop people calling a function from the library in your codebase maybe a similar approach could be adopted.

[raamcosta]

I do not agree it’s the same though. Semantically it’s very different. With unwrap, it’s clear that it is a separate way to get the value without checking it first, whereas .value is the way to get the successful value both before and after checking.

We didn’t even need to disallow it, no one ever used it and most likely no one ever will. I can almost guarantee it that people will use .value though.

(Sorry for not using proper formatting and probably also not explaining it in the best way.. just doing some quick response reaction on the smartphone 😅)

[raamcosta]

Another way of putting it: what you’re saying is almost like saying that there is no point in nullable types because people can !!. It’s maybe not quite, as double bang is even more clear that you’re taking the risk, but it goes in the same direction.

[michaelbull]

what you’re saying is almost like saying that there is no point in nullable types because people can !!

No, I am not saying that.

Fundamentally, what I am saying is that you can type .unwrap() or .value and both have the exact same semantics -> they both give you access to the underlying type without checking, throwing an exception if it's not the presumed type.

If I was to write this project from scratch again, I probably wouldn't have even had the unwrap function to begin with, as accessing the value property is identical in nature.