I'm scratching my head here a bit regarding extension functions. Can someone explain to me why this ...

# getting-started

[mickeelm]

I'm scratching my head here a bit regarding extension functions. Can someone explain to me why this works

private fun <String> HashMap<String, String>.myExt(key: String, incomingValue: String) {
    this[key] = incomingValue
}

But not this

private fun <String> HashMap<String, String>.myExt(key: String, incomingValue: String) {
    this[key] = "something else"
}

The latter gives me (in IntelliJ):

Type mismatch.
Required: String#1 (type parameter of myExt)
Found: kotlin.String

[Joris PZ]

Interestingly, this[key] = "something else" as String fixes the compiler error?

[Joris PZ]

Ah it changes it to a warning about an unchecked cast. Somehow the type of the value in the Map is inferred to be String#1? Seems like a bug

[mickeelm]

Exactly, was just going to write that. So you think it's a bug? I was assuming that I'm missing something

[Joris PZ]

Ah no, wait! It should be

fun HashMap<String, String>.myExt(key: String, incomingValue: String) {
    this[key] = "something else"
}

[Joris PZ]

The initial <String> makes no sense here

[Joris PZ]

Hold on, does it somehow use String as a generic type parameter instead of kotlin.String?

[mickeelm]

Of course! Thank you very much 🙂 It was autogenerated but that makes sense.

[Joris PZ]

You're welcome 🙂

[mickeelm]

Regarding String vs kotlin.String I don't know really

[Milan Hruban]

the String in the original function is just a name you have given to the generic parameter, it has nothing to do with kotlin.String. You could replace it with Abcd (or more often used T) and the function would work exactly same

[mickeelm]

Now that you mention it, it's very clear 😃 thank you! 😃

[Joris PZ]

It surprises me that that is even allowed, the potential for confusion is profound 😀

[Milan Hruban]

how would you prevent it tho? Ban all possible classnames?

[mickeelm]

Yeah I thought about that too, would be kind of tricky tro draw a line there

[nanodeath]

this is a pretty funny issue 🙂 I dunno about banning classnames, but any generic parameter that's not a single character should catch your eye. (I don't love that convention but it's the convention...)

[Matteo Mirk]

I saw code using type parameters longer than a letter, always adopted the Uppercase convention, to avoid confusion. Example:
Message<REQUEST, RESPONSE>
or in Assertj:
interface Assert<SELF extends Assert<SELF, ACTUAL>, ACTUAL> ...