Why the compiler is complaining here, i.e. can't a...

# getting-started

[David Kubecka]

Why the compiler is complaining here, i.e. can't auto-cast?

enum class DateAttribute : UpcomingPaymentAttribute

data class DateKey(val startDate: LocalDate, val granularity: DateAttribute)

...
            // it is UpcomingPaymentAttribute
            when (it) {
                DateAttribute.DAY -> DateKey(LocalDate.now(), it) // here compiler complains that it is UpcomingPaymentAttribute, not DateAttribute

[CLOVIS]

Is it a var ? What's the compiler message?

[David Kubecka]

Type mismatch: inferred type is UpcomingPaymentAttribute but DateAttribute was expected

[David Kubecka]

it is just the standard "default" variable

[CLOVIS]

Could you reproduce it on https://play.kotlinlang.org/? There's not enough information to understand what the problem is

[Goetz Markgraf]

Why should it be of type DateAttribute ? I don’t see any cast.
it is of Type UpcomingPaymentAttribute. In the when expression, I see that it is compared to a value of DateAttribute.DAY. But that does not include, casting it to DateAttribute .

If you had a is DateAttribute in the when expression, than the compiler would cast.

[David Kubecka]

I see. But if it == DateAttribute.DAY then surely it is DateAttribute 🙂 Can I somehow help the compiler realize that (other than manual cast)?

[CLOVIS]

No, you can override equals. If you used ===, then sure.

[Goetz Markgraf]

I was able to reproduce your situation:

interface Parent

enum class Child : Parent {
    THREE, FOUR
}

fun doIt(param: Child) {
    println (param)
}

val a: Parent = Child.THREE

when (a) {
    Child.THREE -> doIt(a)
    Child.FOUR -> {}
}

Two solutions:

when {
    a is Child && a == Child.THREE -> doIt(a)

or

when (a) {
    Child.THREE -> doIt(a as Child)

I’d prefer the second variant.

I agree with you that the compiler actually should be able to cast that.

[CLOVIS]

I disagree with you, I much prefer the first variant. With the first variant, nothing can go wrong. With the second variant, if someone ever overrides equals with a dumb implementation (which would indeed be dumb, but it could happen), it'll crash with ClassCastException, which will be hell to debug.

[David Kubecka]

you can override equals

That's the explanation I was looking for. Thanks!

Although, the consequences are kind of unfortunate because either I will do the explicit cast/check, or go with === losing the exhaustiveness of when

[CLOVIS]

In this case, I would write:

when (it) {
    is YourEnum -> when (it) {
        YourEnum.FirstElement -> …
        YourEnum.SecondElement -> …
    }
    else -> …
}

It's much easier to understand what happens, you have the smart cast and exhaustive checks, and it's probably faster (the inner when on the JVM can be compiled to a native switch)

[Goetz Markgraf]

@CLOVIS Thanx, I did not think of this.
Again a good reminder, why class cast in kotlin is (almost always) a bad idea.

[CLOVIS]

Rule of thumb: if the compiler doesn't trust your is check, you shouldn't either

[Klitos Kyriacou]

Can you give me some sample code in which a silly definition of an overridden equals can lead to unexpected behaviour? I couldn't get it to misbehave the way @CLOVIS suggests:

interface Parent

object O : Parent {
    override fun equals(other: Any?): Boolean {
        return true
    }
}

enum class Child : Parent {
    ONE, TWO;
}

var o: Parent = O

fun main() {
    println(o.equals(Child.ONE)) // true
    println(o == Child.ONE)  // false!
    val n = when (o) {
        Child.ONE -> 1
        Child.TWO -> 2
        O -> 3
        else -> 4
    }
    println(n)  // 3, not 1
}

[Klitos Kyriacou]

So it seems that the when expression will choose the enum value only when the variable is an actual enum type.

[CLOVIS]

Ouch this is so much worse than I thought. On the JVM it uses the enum identity (playground), but on JS it uses the object equality (playground), so this code behaves differently depending on the platform

[CLOVIS]

Reported, please upvote: https://youtrack.jetbrains.com/issue/KT-56879/When-on-an-enum-element-behaves-differently-on-Kotlin-JVM-and-Kotlin-JS

[Klitos Kyriacou]

Upvoted.
Related is the fact that on the JVM (but not on JS) the == operator doesn't seem to call equals (playground). This contradicts the language spec and the documentation.