Is it just me or did anyone else ever felt that it...

# stdlib

[Big Chungus]

Is it just me or did anyone else ever felt that it would be nice to have a KMP expect val Platform along with enum class Platform for all the kotlin platforms along with their target name and other metadata like support tier for instance. I personally would love to have this in the stdlib, but I suspect more apropriate place for it would be s tiny kotlinx library that's released as part of each kotlin release. This would provide a standard way to do platform-branched logic in common sources for apps as well as a nice way for gradle plugins to hook into when integrating with KGP (assuming KGP integrates with this too instead of raw strings). Thoughts?

[Javier]

Yes, it should be there for sure

[Javier]

Can't it be added to Kotlin itself instead of the stdlib?

[Big Chungus]

How do you mean?

[ephemient]

for the record, I think enum class is a bad idea, as that can break existing users when new values are added

[Big Chungus]

Good shout, sealed interface would probably work better

[ephemient]

sealed too, anything you can write an exhaustive when for

[Big Chungus]

With manual "entries" implementation on the companion

[Big Chungus]

Well then a regular abstract class with internal constructor 😂 as long as there's "entries" implementation on the companion

[Big Chungus]

Although now that I think about it, I think I'd much prefer my exhaustive when statements breaking when new platforms are added. Emphasis on mine, not the libraries i use.

[ephemient]

breaking source code is good since you can fix it. but issue is that it silently breaks existing compiled code

[Javier]

as that can break existing users when new values are added

Isn't that expected? I would like a exhaustive when to fail after upgrading Kotlin if it has new targets

[Big Chungus]

Yes, for your own code you can fix, but not for the libraries you use

[Big Chungus]

Since that would halt new version adoption by having to wait for the libraries to update. Similar situation with current compiler plugin compatibility issues.

[ephemient]

or https://youtrack.jetbrains.com/issue/KT-38750

[Javier]

Since that would halt new version adoption by having to wait for the libraries to update. Similar situation with current compiler plugin compatibility issues.

Libraries should add else for example

[Oliver.O]

Caveat: People will derive all sorts of seemingly platform-dependent features from a "platform type", which are not really there in practice or which break a former association with a specific platform in a future release. Rabbit holes like this existed in the early days of C on Unix/Linux, platform constants evolved into fine-grained feature sets (see GNU autoconf for an example), but the underlying problem sort of remains.