Is it just me or did anyone else ever felt that it...
# stdlib
b
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?
j
Yes, it should be there for sure
Can't it be added to Kotlin itself instead of the stdlib?
b
How do you mean?
e
for the record, I think
enum class
is a bad idea, as that can break existing users when new values are added
b
Good shout, sealed interface would probably work better
e
sealed too, anything you can write an exhaustive
when
for
b
With manual "entries" implementation on the companion
Well then a regular abstract class with internal constructor ­čśé as long as there's "entries" implementation on the companion
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.
e
breaking source code is good since you can fix it. but issue is that it silently breaks existing compiled code
j
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
b
Yes, for your own code you can fix, but not for the libraries you use
Since that would halt new version adoption by having to wait for the libraries to update. Similar situation with current compiler plugin compatibility issues.
e
j
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
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.