What is the usage of the <T> type parameter before the function name in Kotlin?
Example:
fun <T> MutableList<T>.swap(index1: Int, index2: Int) {
val tmp = this[index1]
this[index1] = this[index2]
this[index2] = tmp
}
Referring to the first <T> above.
I've tried to look through the Kotlin docs regarding generics as well as the Java Generics however they mostly just touch on the 2nd <T> not the first.
It is used to indicate that generics are used and not some type T is referenced.
Have a look at this completly valid example
fun <String> MutableList<String>.swap(index1: Int, index2: Int)
Now this can be called on any MutableList<*> and not only MutableList<String>. If you would not write <String> after the fun keyword, how would kotlin know that in fact you were referencing a generic and not kotlin.String?
The same goes for the example you've shown. The <> after the fun just introduces a new generic parameter, else kotlin would complain that it wouldn't know the type T
(Here's another approach.)
Consider a normal, non-generic function:
fun myFun(a: Int, b: String) {
// …use a and b…
}
What are a and b? They don't mean anything yet. They're simply saying ‘When you call this function, you must pass these values’. You'd expect the body of the function to refer to them in some way; that's when they get used.
Now consider a generic function:
fun <T, U> myFun(/* …use T and U… */) {
// …
}
It's the same with T and U. Those are parameters, too — type parameters. Just like with value parameters, declaring type parameters doesn't mean anything by itself, but gives placeholders for types that must be passed (explicitly or inferred) when calling the function. (The <…> declaration also gives a place to specify any constraints or variance, e.g. <T : Number> or <out T>.) And you'd normally use those type parameters later on — in this case, in the rest of the function signature.
To add to Lino's answer, imagine this definition has invisible braces after type parameter declaration:
fun <T> \*{*\ MutableList<T>.swap(index1: Int, index2: Int) {...} \*}*\
So it's properly lexically scoped. If that <T> went after function name, you'd lose this property, complicate the parser, and only make code less readable for humans.
It would also be hard to remember to put <T> before name for extension functions, but after it for member functions. Bad enough that it has to be done for classes!
Scala does put [T] after the method name, but that's because it has a very different syntax for the feature corresponding to extension methods. Scala 3 will go for the complicated parser approach, probably because Kotlin-like syntax would not fit with any other syntax.