Did something change with exhaustive when validati...
# announcements
j
Did something change with exhaustive when validation in 1.5? I found nothing in the breaking changes list: https://kotlinlang.org/docs/compatibility-guide-15.html I have an exhaustive when (in my common code) on an
expect sealed class
(coming from Ktor multiplatform client), which used to compile fine (on 1.4.31), but now throws the following error:
Copy code
when with expect sealed class as subject can not be exhaustive without else branch
I've seen this bug: https://youtrack.jetbrains.com/issue/KT-43875 but it seems to report a problem on 1.4, while my code used to compile fine on 1.4.31
y
I'm guessing that it's because sealed class inheritors can now be all around the module, and so the actual sealed classes in the platform-specific sources can have extra classes inheriting the sealed class that aren't expected
🙏 1
This is one of the provided simple test cases in the compiler:
Copy code
// !LANGUAGE: +MultiPlatformProjects
// !DIAGNOSTICS: -UNUSED_VARIABLE
// ISSUE: KT-20306

// MODULE: m1-common
// FILE: common.kt
expect enum class Base {
    A, B
}

fun testCommon(base: Base) {
    val x = when (base) { // must be an error
        Base.A -> 1
        Base.B -> 2
    }
}

// MODULE: m1-jvm(m1-common)
// FILE: Base.kt
actual enum class Base {
    A, B, C
}

fun testPlatformGood(base: Base) {
    val x = when (base) { // must be OK
        Base.A -> 1
        Base.B -> 2
        Base.C -> 3
    }
}

fun testPlatformBad(base: Base) {
    val x = <!NO_ELSE_IN_WHEN!>when<!> (base) { // must be an error
        Base.A -> 1
        Base.B -> 2
    }
}
j
Thank you! I can understand the reason for such a change, I just wanted to make sure this was not a bug. If it's intentional, I think it should appear in the breaking changes list, I didn't find it there: https://kotlinlang.org/docs/compatibility-guide-15.html
s
I sort of get the change, but it almost feels like it strongly diminishes the idea behind sealed classes. Is there a PR/document that shows the thought process more behind this change?
y
@Strum355 again it is due to the fact that an
expect sealed class
can have unexpected inheritors, and so it's only safe to use it exhaustively in platform code not common code. If you need exhaustiveness in common code, then make it a normal
sealed class
and make all the inheritors
expect
instead
s
Ohh so this is something specific to multiplatform and with a specific keyword. Okay that alleviates my concerns, thanks 🙂
🙌 1
e
It is not listed as breaking, because multiplatform is still experimental.
j
Ah makes sense, I keep forgetting that the whole multiplatform support is experimental. Thanks!