:wave: I wanted to see what the community thinks about enums in Kotlin. I had a discussion with a co...

# kotlin-native

[Zsolt Bencze]

👋 I wanted to see what the community thinks about enums in Kotlin. I had a discussion with a colleague and I learned that enums seem to be taking a back seat to sealed classes and interfaces. I was really surprised given that I come from a Swift background where enums are very important and widely used.

[jw]

Swift enums and other language's enums (such as Rust) are far closer to sealed hierarchies than Kotlin's extremely basic, JVM-inspired(/limited) version of enums

[ephemient]

since you're familiar with Swift: JVM enums cannot have associated values

[ephemient]

so while Swift's

enum Foo {
    case bar, baz
}

is mostly equivalent to

enum class Foo {
    bar, baz
}

you can't translate

enum Foo {
    case bar(Int)
    case baz
}

to a Kotlin enum class

[Zsolt Bencze]

I see.. I understand now. Enums in Kotlin are not equal to Swift in Kotlin.

[ephemient]

that would be more closely represented by

sealed class Foo {
    data class Bar(val value: Int) : Foo()
    object Baz : Foo()
}

instead. of course you could also translate an enum without associated values to `sealed class`+`object`, but while the usage is pretty similar in Kotlin, you lose some of the Java conveniences of enum that way

[kevin.cianfarini]

Is there much difference on a machine code / bytecode level? I assume enums are better because it doesn’t require virtual dispatch whereas sealed hierarchies would. I don’t know if there’s other ancillary benefits too, though

[ephemient]

some previous discussion: https://kotlinlang.slack.com/archives/C0B8MA7FA/p1668509625939619

[ephemient]

there is a bit of a difference in bytecode, yes. virtual dispatch is… maybe confusing

[jw]

enums are basically sealed value classes. so once we get those enums will mostly be obsolete aside from a syntactical terseness where they have an implicit backing integer and auto-assigned ordinals

[kevin.cianfarini]

That’s a good point — referring to an instance of an enum by it’s ordinal is often a footgun. Especially for things like db persistence.

[jw]

although sealed value classes can still box whereas enums are always boxed-by-default. you pass around the reference rather than the underlying ordinal. so still slightly different

[ephemient]

enum class Foo {
    Bar,
    Baz {
        override fun toString(): String = "baz"
    }
}

in bytecode this looks sorta like what

class Foo private constructor(override val name: String) : Enum<Foo> {
    override fun toString(): String = name

    private class Baz(name: String) : Foo(name) {
        override fun toString(): String = "baz"
    }

    companion object {
        @JvmField
        val Bar = Foo("bar")
        @JvmField
        val Baz = Baz("baz")
        @JvmStatic
        fun values(): Array<Foo> = arrayOf(Bar, Baz)
    }
}

would compile to, except that you aren't allowed to subclass Enum yourself

[ephemient]

(plus some other enum magic like ordinal and valueOf)

[Zsolt Bencze]

This is really helpful, thanks!