Variance for function output types is ignored

[DanySK]

Describe the bug

Generating this function is impossible:

fun <T> foo(): Array<out T> = TODO()

Note that this prevents an entire family of functions from being generated

To Reproduce

Run this:

fun main(args: Array<String>) {
    val funspec = FunSpec.builder("foo")
        .addTypeVariable(TypeVariableName("T"))
        .returns(
            ClassName.bestGuess("kotlin.Array")
                .parameterizedBy(TypeVariableName("T", variance = KModifier.OUT))
        )
        .addStatement("TODO()")
        .build()
    println(
        FileSpec.builder("foo.bar", "Baz")
        .addFunction(funspec)
        .build()
        .toString()
    )
}

Expected:

package foo.bar

import kotlin.Array

public fun <T> foo(): Array<out T> {
  TODO()
}

actual:

package foo.bar

import kotlin.Array

public fun <T> foo(): Array<T> {
  TODO()
}

Expected behavior
See above

Additional context
Stumbled on this while building a code generator that wraps fun Array<out T>?.orEmpty(): Array<out T>.
I can only generate: fun <reified T, ID : Any> Field<ID, Array<T>?>.orEmpty(): Array<T>, but I need fun <reified T, ID : Any> Field<ID, Array<T>?>.orEmpty(): Array<out T> for the compilation to succeed.

Alternatively (but it is a workaround) it should be allowed to omit the return type and let the compiler infer (in my case, fun <reified T, ID : Any> Field<ID, Array<T>?>.orEmpty() = ... would work

[Egorand]

Here's what you can do:

fun main(args: Array<String>) {
    val funspec = FunSpec.builder("foo")
        .addTypeVariable(TypeVariableName("T"))
        .returns(ARRAY.plusParameter(WildcardTypeName.producerOf(TypeVariableName("T"))))
        .addStatement("TODO()")
        .build()
    println(
        FileSpec.builder("foo.bar", "Baz")
        .addFunction(funspec)
        .build()
        .toString()
    )
}

which also feels slightly more semantically correct, but I guess we do need to be able to correctly print out types parameterized by type variables, since TypeVariableName is TypeName?

[DanySK]

Yes, I tried to exemplify a simple case, but what I am doing in practice is detecting the signature of an existing function and creating a new one with the same parameterized return type. So I cannot statically refer to ARRAY or any other type specifically, it can be an arbitrary type that is discovered at runtime (when running the code generation).
I'd like to be able to parameterize these return types with co(ntra)variant type variables and have their variance reflected in the function signature.

[Egorand]

Yes, I tried to exemplify a simple case, but what I am doing in practice is detecting the signature of an existing function and creating a new one with the same parameterized return type. So I cannot statically refer to ARRAY or any other type specifically, it can be an arbitrary type that is discovered at runtime (when running the code generation). I'd like to be able to parameterize these return types with co(ntra)variant type variables and have their variance reflected in the function signature.

In that case you can use ClassName.bestGuess() as showcased by your example and parameterize it with WildcardTypeName.producerOf(TypeVariableName("T")).

[DanySK]

The workaround works. I can close this issue, but I think that at least this behavior should be documented in parameterizedBy, suggesting to call WildcardTypeName.(producer|consumer)Of(TypeVariableName) for explicitly co(ntra)variant types.

[Egorand]

Agree with keeping it open, I don't see any reason your original code shouldn't work, so that's still a bug.

[JakeWharton]

I think I'd like to argue this is working as intended. And possibly, instead, that we have an API design problem here. The variance on a type parameter should only exist when we declare a type parameter, not when we use it. When we use variance within a type (regardless of whether it's a type parameter or not) there's a consistent way to do that. And that use of variance in a type is separate from the declaration of the type parameter.

[DanySK]

@JakeWharton do I understand correctly that you want to differentiate between the type variable declaration-site variance and use-site variance (projection)?

It makes sense in principle, but in Kotlin variance annotations are only allowed for type parameters of classes and interfaces. Use-site variance is useful when you have an invariant type that needs projection:

data class Invariant<T>(var x: T)

fun <T> covariant(x: T): Invariant<out T> = Invariant(x)
fun <T> contravariant(x: T): Invariant<in T> = Invariant(x)

fun main() {
    val covariant = covariant(1)
    val contravariant = contravariant(1)
    val x: Int = covariant.x // OK
    contravariant.x = 2 // OK
    covariant.x = 1 // Assignment type mismatch: actual type is 'kotlin.Int', but 'kotlin.Nothing' was expected.
    val y: Int = contravariant.x // Initializer type mismatch: expected 'kotlin.Int', actual 'CapturedType(in kotlin.Int)'.
    println(covariant(1))
}

Note that you can always re-declare variance at use site (it's a compiler warning).