A modern programming language that makes developers happier.

kotlinlang

Hey folks, question about `@UnsafeVariance`. If I am defining some `Container<out T>` class and I want one of its methods to return `Optional<T>` (for Java users), then is it safe/reasonable to do `Optional<@UnsafeVariance T>`? I don't want to do `Optional<out T>` since that will end up being `Optional<? extends T>` for Java users, which is annoying to work with.

I think using `@UnsafeVariance` here makes sense because `Optional` is an immutable container so you can only get `T` out of it; you can't put a new `T` into an existing `Optional<T>`. It's just that Java obviously does not define `Optional` with `out T` at it's declaration (since it's not Kotlin)

Am I making sense? Am I missing anything here?

Is it possible to make the method for Java users an extension function instead? Example:
```import java.util.Optional

class Container&lt;out T&gt;(val v: T?)

fun &lt;U: Any&gt; Container&lt;U&gt;.optional(): Optional&lt;U&gt; =
    Optional.ofNullable(v)

fun main() {
    val c = Container(3)
    println(c.optional())
}```

Ah, interesting. Do extension functions get exposed to Java users as functions _on_ the class though? I would have assumed they get exposed as standalone functions that take the receiver as the first parameter or something

&gt; I would have assumed they get exposed as standalone functions that take the receiver as the first parameter or something
That's exactly what happens, yes.

Yeah, I would like to avoid that if possible, since it's not as ergonomic

To clarify, the `Container<out T>` thing was a simplified example vs what the class actually does

I was mainly trying to illustrate a simplified scenario to see if my understanding of `@UnsafeVariance` is correct

But I can provide more details if that'd help

`@UnsafeVariance` is fine in your case. The reason Kotlin forbids just returning `Optional&lt;T&gt;` is code like this:
```interface MutableOptional&lt;T&gt; {
    fun mutate(newValue: T)
}

class Container&lt;out T&gt;(v: T) {
    
    private var vValue: T = v

    fun optional(): MutableOptional&lt;@UnsafeVariance T&gt; = object: MutableOptional&lt;@UnsafeVariance T&gt; {
        override fun mutate(newValue: @UnsafeVariance T) {
            vValue = newValue
        }
    }
    
    val v: T get() = vValue
}

fun main() {
    val c = Container&lt;Int&gt;(3)
    val c2: Container&lt;Any?&gt; = c
    val o: MutableOptional&lt;Any?&gt; = c2.optional()
    o.mutate("4.3")
    println(c.v + 10) // throws an exception
}```
When it comes to just the variance, `Optional` and `MutableOptional` are the indistinguishable.

Java's `Optional` *could* have been marked with `out` as well, which means that your users can't really do anything with it that would break the guarantees of your container.

So the reason it's safe for Java's `Optional&lt;T&gt;` is because the container cannot be mutated, right?

Nice nice, thanks for the explanations/example :slightly_smiling_face: