Given enums can’t subclass other classes, a sealed class would not work. One example of this would be enum classes that implement interfaces. If we use interfaces across the board and there comes the need to limit the possible implementations of it, sealed class is not a valid replacement for all the cases. That way both library devs and clients can leverage exhaustive evaluation over a contract represented by an interface without leaking any internal implementations.īut truth is you could achieve the same with a sealed class, given they share the same limitation. That is very welcome for library makers ✅ When we limit the implementations per module, our library can have public sealed interfaces as part of its API surface, therefore hiding the internal implementations of it and ensuring they’ll not get extra implementations provided by the client. Note that this change is also experimental. Vehicle.kt sealed interface Vehicle // Cars.kt object FuelCar : Vehicle object ElectricCar : Vehicle // Trains.kt object HighSpeedRail : Vehicle object MonoRail : Vehicle object Tram : Vehicle object InterCity : Vehicle // Plane.kt object Airliner : Vehicle object Ultralight : Vehicle

This ability to split declarations will also go for sealed interfaces. The aim is also to allow splitting large sealed class hierarchies into different files to make things more readable. This is also possible for sealed classes and sealed interfaces in Java 15. The Kotlin compiler can still ensure exhaustiveness given that the module is compiled together. This restricts it to only implementations that “you own”.

Starting on Kotlin 1.5 location restrictions will get relaxed, so we can declare them on different files under the same module. Kotlin 1.1 made it possible to declare those within the same file. Until not long ago, the compiler was not capable of looking further than the scope of the sealed class itself, so it was forbidden to declare subclasses outside of it. It needs to know about all the subclasses available in order to ensure exhaustiveness. Limitations on where to write the subclasses of a sealed class are a matter of compiler awareness. You can give feedback on them in YouTrack. They may be dropped or changed at any time.

Short overview of the sealed interfaces coming up in Kotlin 1.5.

Internal kotlin