I'm having some problems with variance. I'm making my own result type:

sealed class Result<out T> {
  class Success<out T>(val value: T): Result<T>()
  class Failure<out T>(val error: MyError): Result<T>()

  fun orDefault(d: T): T = when (this) {
    is Success<T> -> this.value
    is Failure<T> -> d
  }
}

I understand why it doesn't work, T is in

in

position when I marked it as

out

, what I want to know is: Is there some syntax to make

T

invariant or contravariant just for that method?

What if you make it an extension function?

fun <T> Result<T>.orDefault(d: T): T = when (this) {
    is Result.Success<T> -> this.value
    is Result.Failure<T> -> d
}

If there is no other way, I'll give it a go and see how it feels, thanks!

Actually this makes sense. Let's assume you could define that function like you wanted to. Now take a

Result<String>

. Because

Result

is

out T

, you can assign this object to a variable of type

Result<Any>

. Now you can call

orDefault

on that variable, and it has to accept

Any

as input, so this means in

Result<String>.orDefault()

you can get a value of type

Any

- you can't restrict it to T:

val anyResult: Result<Any> = Result.Success<String>("str")

anyResult.orDefault( ... ) // will accept Any here, so Result<String> must accept Any

yeah, that makes sense

You can't have your cake and eat it too 😄 so you have to either forbid

val anyResult: Result<Any> = Result.Success<String>("str")

by removing the

out

, or accept any type in

orDefault()

(which is totally OK IMO, because the return type will still be very useful)

if I have

Result<String>

and I

orDefault

with a

String

, I get back a

String

and not

Any

right?

Yes exactly, that's the beauty of it. That's why I think it's fine. It's still strict on the return type if you're using the default value type matching the result's type, but it also allows you to get a wider return type if that's what you want by providing any default value you want

As to the original question, Intellij Idea suggests `@UnsafeVariance`:

sealed class Result<out T> {
    class Success<out T>(val value: T): Result<T>()
    class Failure<out T>(val error: Exception): Result<T>()

    fun orDefault(d: @UnsafeVariance T): T = when (this) {
        is Success<T> -> this.value
        is Failure<T> -> d
    }
}

Then

orDefault

is limited to be of the original

T

. But to be honest, I'm not up to speed with variance and can't comment on potential drawbacks.

Yeah that's actually an option too. It doesn't guarantee that

T

is the original

T

- because your instance could be assigned to a variable with wider

T

type. But it still works because

out

guarantees that

T

in this method will at least be a supertype of the actual

T

. And given what is done inside the method it's ok to return `this.value`if

T

is a supertype of the actual value's type. So in essence it prevents direct

orDefault()

call with a different type, but still doesn't protect against:

val anyResult: Result<Any> = Result.Success<String>("str")

anyResult.orDefault(42) // returns Any, or maybe Comparable

So yeah it can be useful if you want to make it harder to use default values of different types. But I'm not sure this is really necessary. It's like using

when

expressions with different types in different branches (it's actually literally this):

val value = when(...) {
   ... -> 42
   ... -> "str"
}

To me this is OK, since anyway the type of

value

will be as specific as it can be. So the same goes for

orDefault()

IMO.