Somewhat related: this is probably debatable, but ...

# library-development

[bod]

Somewhat related: this is probably debatable, but I wish typealiases of a deprecated type would not trigger a deprecation warning. This would help libraries “soft rename” types.

@Deprecated("Use NewName instead")
class OldName

typealias NewName = OldName

// ...
val x = OldName() // <- warning
val y = NewName() // <- warning too, bummer.

[CLOVIS]

Once the typealias changes meaning it's a binary-breaking change, so it would still require a major version in the end

[bod]

Not sure I get what you mean. Neither adding a deprecation or a typealias breaking, right? The fact that using the typealias doesn't warn shouldn't break either?

[CLOVIS]

I mean that this kind of soft rename isn't really as soft as it seems. Typically, you'd have:
• v1.2: create NewName typealias
• v1.3: deprecate OldName
• v2: remove OldName and make NewName a class
If I'm a user of v1.3 and I use the typealias NewName , which is not deprecated, my code will still be broken if it runs with a v2 version of the library

[bod]

Ha you're right... It's temporarily a soft rename, but only pushes the issues to later 😅.

[bod]

OTOH maybe the last step doesn't have to happen

[CLOVIS]

But then why deprecate OldName , if you can't ever remove it?

[bod]

I guess, just so the API is nicer / easier to understand, with a more correct naming.
In the JDK and Android some symbols have been deprecated since forever, and will probably stay there forever too.

[CLOVIS]

I guess then it's safe 🤔

[bod]

Food for thoughts!

[ephemient]

you may be interested in https://youtrack.jetbrains.com/issue/KT-36949/Allow-JvmName-on-types

[bod]

Didn't even think of @JvmName("SparseArrayCompat") but yeah having it on types would be useful! Thanks for linking. ⭐