A modern programming language that makes developers happier.

kotlinlang

:wave: 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.

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

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

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`

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

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

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

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

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

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

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.

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

```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&lt;Foo&gt; {
    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&lt;Foo&gt; = arrayOf(Bar, Baz)
    }
}```
would compile to, except that you aren't allowed to subclass `Enum` yourself

(plus some other enum magic like ordinal and valueOf)