Why ALL diamond types are required when calling Inline reified function?

1

Image is worth 1000 words :slight_smile:

image
image989×282 22 KB

public inline fun <reified OUT, IN> test(input: IN) {}

fun main() {
    // Why input type is not recognized? Why is forcing me to defined input type again in diamond bracket???
    test<TableInfo>(input = String())

    // And now its working
    test<TableInfo, String>(input = String())
}

Is this limitation of inline reified functions, or is it a bug?

1 Like
2

How could the compiler know you provided the OUT and not IN? Kotlin definitely could do better here, but as for now, we can do this: test<TableInfo, _>.

BTW, imgae is worth 1000 words, but it doesn’t help the reader to reproduce your problem and ultimately, help you solve your problem :slight_smile:

1 Like
3

Oooh i see, hmmm now that you point that out it does make sense that compiler strugles with it.

I end up doing like this…

public fun <OUT, IN> test(output: KClass<OUT>, input: IN){}

fun main(){
     test(TableInfo::class, String())
}

Oh and of course I forgot to add the code, I’m sorry!
I added now!

4

It would be cool if you could mark generic type with some anotation so that compiler knows
which types he chould infere from the usage… For example like this…

public inline fun <reified OUT, infered IN> test(output: KClass<OUT>, input: IN){}

fun main(){
     test<TableInfo>(String())
}

Should I make feature request on kotlin youtrack? What you guys think?

5

Yeah, I agree. As a matter of fact, before writing my comment, I checked if there is exactly such feature as you described, because Kotlin has a few similar hidden features to control the inference of type parameters: kotlin/libraries/stdlib/src/kotlin/internal/Annotations.kt at master · JetBrains/kotlin · GitHub Unfortunately, I don’t see anything like: @AlwaysInfer.

2 Likes
6

@broot Thank you brother, I have created Kotlin YouTrack issue related to this problem.