I'm curious as to the risks of renaming a type par...

# getting-started

[CLOVIS]

I'm curious as to the risks of renaming a type parameter.
• Source-compatibility: as far as I know, they are always positional and never written explicitly in user code, so it should be ok?
• Binary-compatibility: as far as I know, they do not even appear in Java bytecode. Maybe they appear in the klib files?

[mkrussel]

Kotlin supports changing the order when using named arguments, so source compatibility is broken.

For binary, not sure if it has some impact on default parameter handling and the synthetic methods.

[CLOVIS]

Kotlin supports changing the order when using named arguments, so source compatibility is broken.

What's the syntax?

[mkrussel]

Point(x = 5, y = 10) == Point(y = 10, x = 5)

[CLOVIS]

I'm talking about type parameters, not value parameters. To my knowledge, there's no named way to specify them (playground).

[mkrussel]

And the fun problem is that you cannot deprecate the old function with the wrong name since the position order would remain the same.

[mkrussel]

Then ignore everything I said

[hfhbd]

Yes, you can rename the type parameter because the names aren't stored anywhere. See also: https://youtrack.jetbrains.com/issue/KT-51954/Named-generic-type-arguments

[CLOVIS]

Thanks, this was the authoritative comment I was searching for:

https://kotlinlang.slack.com/archives/C0B9K7EP2/p1643211198015700?thread_ts=1643209525.015500&cid=C0B9K7EP2