A modern programming language that makes developers happier.

kotlinlang

Can any KMP [JB] folks comment on this pretty nasty Enum class related bug in *Kotlin 2.x* which has gone unresolved for a long time:

<https://youtrack.jetbrains.com/issue/KT-56107|KT-56107> Fix broken Enum.entries resolve in C interop in K/N
...caused by...
<https://youtrack.jetbrains.com/issue/KT-53929/Enum.entries-consider-changing-scope-behavior-in-K1|KT-53929> Enum.entries-consider-changing-scope-behavior-in-K1

I'm going to have to do _quite a lot_ of refactoring to work around it. :kodee-angry:  Worst bug/regression in Kotlin I've seen in a long time :kodee-sad:

Okey, I managed to reproduce the issue.

Do I understand correctly your setup:
• You have an expect enum, actualized by enum comming from CInterop.
• You don't use `.entries` used in common code (becuase it didn't work in 1.9 either).
• In 1.9 it worked accidentially, because check was lost (but example above shows it's needed). 
• In 2.0 it was changed within other fixes in multiplatform made more strict (as now common code is compilated separately, and all this problems arised). 
• Now you can't actualize typealias to interop class, as it doesn't match (which is correct), and need to workaround it by some strange hacks?  

Hi <@U02K3A6E6KD> - thanks for taking the time to look into this; it's appreciated. :bow:

Yes, your assessment is correct - I'm doing `expect enum class` and `actual`-ising it with an Obj-C Enum.
The number and identities of the enum members is not significant, only the substitution of the `enum` type.
I also don't make explicit use of `.entries` as you mentioned.

To add some context; one of my use cases is to commonise a decimal `RoundingMode` between the distinct rounding-mode enums that accompany each of *JVM BigDecimal* and *iOS NSDecimalNumber.*

Why would it be _'not correct'_ to `actual typealias` to an interop class - as long as that has equivalent modality, which an ObjC enum does?
I assume you mean _'not correct'_ according to the world-view of the current _implementation_, since there should be no conceptual problem with this: its just 'yet another' type substitution - unless I'm missing something?
All seemed consistent and functional in `1.9` even if 'by accident'.

I refactored my code to work around it but the code is not as elegant.

As things stand now in 2.x you can't use `expect` / `actual` with enum classes if you have a Kotlin/Native target, which can be seen as a significant Multiplatform language limitation introduced in 2.x - in practice if not intent.

Do you see a pathway to re-enabling this?

It's "not correct" because it break "if common code compile on its own, then it's compiled after substitution". Because you can use `.entries` on expect enum, and it would break. 

It's not the case for now, but we are actively working on common modules of dependees being resolved to dependency common part. And after this it would be broken even more. 

I would say it definitely should be supported, but not by lifting the restriction, but by adding `.entries` to interop enums, which should be doable.

Ok, is there anything I can do to help next step e.g. raise new ticket or add this note to existing one?

Adding `.entries` to interop enum sounds right, to complete the general contract of an enum.

What is enum except a class with fixed number of entries after all?

No, I would update existing one with mentioning additional use case.