kind of an academic, please-don’t-think-I’m-actually-using-this sorta question - is there any sort o...

# announcements

[Shawn]

kind of an academic, please-don’t-think-I’m-actually-using-this sorta question - is there any sort of provision to have two methods with the same name and signature, but with one having a type parameter (specifically reified vs no type param, (thanks for clarifying @halley))? the compiler complains about a platform declaration clash, which I suppose makes sense since there’s no real overloading happening there, but since the second method has to be inline anyhow, could the compiler not figure out what you mean at compile time and inline the appropriate method to avoid the signature clash?

[halley]

Problem I could see is... if a consumer tries to use that method, the compiler wouldn't know which signature to match up between the regular or reified one

[josephivie]

Does @JvmName work for your case? You can just give each function a different name for the JVM but leave the same name for Kotlin

[Shawn]

Eh, I don’t have a specific case actually, this is just a result of me plonking around in a scratch file as I try to survive Thanksgiving

[Shawn]

Also @halley I’m not 100% certain what you mean - I figured with reified in play, the compiler could discern between foo() and foo<Bar>(), but I don’t know much about computers tbh

[halley]

If you have both fun <T> foo(T t) and fun <reified T> foo(T t) defined somewhere.

If you have a consumer making this call foo<Bar>(bar), which one would it call?

[Shawn]

Ah, that’s a good point! What I was thinking of was more like this

fun foo()
inline fun <reified T> foo()

only one is generic, no other args, etc

[halley]

Due to erasure, it's the same signature.

[halley]

It's a void return, with noargs

[Shawn]

I mean, sure, once said function makes it to the method table - I guess I was wondering if it’d be possible with `inline`/`reified` for the compiler to perform the inlining before that point and essentially erase the existence of this second method from the JVM’s point of view

[Shawn]

But maybe not - I’m not trying to argue that this is or should be possible or anything - just asking to further my understanding of the compilation process

[Shawn]

maybe it’d be analogous to macro preprocessing

[Dico]

You can call the function that takes a type parameter implicitly, because the type can be inferred. In that case, your expression is foo() and there's no way the compiler can tell the two Kotlin functions apart. It does not consider return type when resolving this call. That would make any JVM related constraints (like @JvmName) meaningless. At least, that's what I would think.