Why would I use `_enumValues_<Platform>()` over `Platform.values()`?

# getting-started

[Vampire]

Why would I use _enumValues_<Platform>() over Platform.values()?

[Joffrey]

Most likely when it's not a fixed Platform enum type, but a reified generic enum type

[Vampire]

thx

[Vampire]

Makes sense

[Javier]

values is not deprecated so now it is entries? Is there any enumEntries<T> there?

[Joffrey]

I don't think there is an entries-based replacement for enumValues yet, but I may be wrong

[Joffrey]

However, you're right that the second example Platform.values() should be replaced by Platform.entries in all modern code bases

[Kilian]

_enumValues_<Platform>() oh boy didn’t knew about this that’s perfect 😄

[Vampire]

should be replaced by Platform.entries in all modern code bases

Gradle build logic, so no 1.9 yet 🙂

[Joffrey]

I feel you, but Gradle 8.3 is just around the corner with embedded Kotlin 1.9 🙂

[Joffrey]

Ah wait, the language level will not be updated, my bad

[Vampire]

Wouldn't change anything, Language version will most likely change earliest in Gradle 9

[Joffrey]

Yep, sorry 😅

[Vampire]

Besides, that the build I'm trying to change something right now is still on 5.6 😞

[Joffrey]

Then I'm glad I carefully used the phrase modern code bases in my previous comment 😄

[Klitos Kyriacou]

There's this documented:
https://kotlinlang.org/api/kotlinx-metadata-jvm/kotlinx-metadata-jvm/kotlinx.metadata/-km-class/enum-entries.html
but I don't think it's meant for mere mortals.

[Marcin Wisniowski]

Kotlin 1.8 considered "not modern", meanwhile some companies are still having a hard time migrating from Java 8 to Java 11 🙃