Since I updated a project from 1.3.40 to 1.3.70 I'...

# multiplatform

[Leon Linhart]

Since I updated a project from 1.3.40 to 1.3.70 I'm getting Enum class 'TimeUnit' has several compatible actual declarations in modules [...]. Apparently this is caused by an (artificial?) restriction that only allows a type to serve as actual typealias once. Now I'm curious if this is a deliberate design decision.
Unfortunately, in this case it becomes impossible to use my own TimeUnit implementation instead of DurationUnit (which is still experimental). Additionally, such a change (addition of an actual type alias) seems to be source incompatible and most library authors are probably not aware of this.

[russhwolf]

This youtrack ticket tracks that actual typealias limitation FYI. I don't think it's a deliberate design decision since it only applies for expect/actual, not general typealiases
https://youtrack.jetbrains.com/issue/KT-29341

[Leon Linhart]

Thanks for the pointer but I don't think that's the issue I'm facing. I used to have a expect enum TimeUnit in my common code and a typealias (actual typealias TimeUnit = java.util.concurrent.TimeUnit) in my JVM code. When I update to Kotlin >= 1.3.50 (where the Duration API was added), my code does not compile. Seemingly that is due to the addition of actual typealias DurationUnit = java.util.concurrent.TimeUnit in the Kotlin stdlib.

I'll have another look at this later and open a ticket for it if appropriate.

[russhwolf]

Oh so your issue is having multiple typealiases that point to the same thing? That does sound different (and strange)

[Leon Linhart]

Yes, seems like it at least. I'll confirm later.

[Leon Linhart]

Cannot reproduce on a clean project. I guess I'll blame it on https://youtrack.jetbrains.com/issue/KT-35957. (I thought I disabled incremental compilation but it seems I messed up here.)