Generic type parameters position

Language Design
1

Hey guys, I would like to share a really trivial thought about the way we declare generic classes and functions in Kotlin.
I am relatively new to the language (having used Kotlin for ~6 months), I have always thought that the way we declare generic classes and generic functions is a bit inconsistent.

// a generic class (type parameter declared after name)
class GenericClass<T> { ... }

// a generic function (type parameter declared before name)
fun <T> genericFunction() { ... }

// a generic extension function (type parameter declared before name)
fun <T> T.genericFunction() { ... }

At first, I thought it looks nicer to declare the type parameters after the function name for consistency, but I realize the possibility of extension functions.

class GenericClass<T> { ... }

// type parameters after the function name, which seems nice...
fun genericFunction<T>() { ... }

// the type parameter is used before it is declared, not good
fun T.genericFunction<T>() { ... }

So, it seems that allowing type parameters declared after function names is not possible. However, I think we could also allow the type parameters to be declared before the class name for consistencies.

// this actually looks nice too
class <T> GenericClass { ... }

// consistent with these
fun <T> genericFunction() { ... }
fun <T> T.genericFunction() { ... }

As a beginner, I have been having a bit of difficulty remembering where is the type parameter list declared when I am writing generic functions and classes. I think this would help haha. What do you guys think?

4 Likes
2

While I agree that the small inconsistency in generic type parameter declaration order on functions and types may be initially confusing to beginners, I believe that the current syntax has some benefits.

For instance, there are many cases where placing the generic type parameter list after the class name reads much more natural. A good example would probably be most generic container types, where something like List<T> or Set<T> naturally reads like “a List of Ts” or “a Set of Ts”. I believe this natural way of reading a class declaration would be lost if instead we declared generics before the class as you suggest class <T> List / class <T> Set.

While this would probably also hold true for many generic function declarations you already pointed out yourself that there are some reasons why specifically on functions, it is useful to have a different declaration order due to generic receiver types.

I don’t think that Kotlin should allow declaring generic type parameters before the class name in addition to the current syntax, mainly because it seems like the added benefit would be minimal while also introducing multiple ways of declaring the exact same construct.

3 Likes
3

Well explained!
I think you nailed the point of how List reads better than Class,

I am actually secretly hoping they would allow type parameters to be declared after the function name like how we invoke functions, despite possible parsing difficulties with generic receiver types. Lol

Thank you for your reply, well said.

2 Likes