I ran into this problem several times over the last few weeks. It is really quite obnoxious, and I have not found any really good workaround for the problem when it happens. I had to basically make my class non-sealed in order to work around the problem, thus requiring useless ‘else’ clauses in my ‘when’ clauses that would have been unnecessary otherwise.
My most recent case was like this:
in package com.example.interfaces:
sealed interface S
interface S1 : S
interface S2 : S
// abstract class Abstract2 : S // see below
in package com.example.implementation:
abstract class Abstract : S // This currently errors out ( :-( ), but I don't think it should (see below).
class S1Impl : Abstract, S1 // Should be OK: non-abstract and inherits an S alternative (S1)
class S2Impl : Abstract, S2 // Should be OK: non-abstract and inherits an S alternative (S2)
class Nope : S // Should be an error (since Nope inherits S (but not S1 or S2) and is not abstract).
class Nope2 : AbstractS // Should also be an error (Nope2 inherits S (but not S1 or S2) and is not abstract.
Several things I noticed:
#1: With Kotlin’s current design, class Abstract triggers a compiler error. However, as far as I can tell, there is really no reason to prevent an abstract class in another package from inheriting from a sealed class or interface. There is only really a reason to prevent a non-abstract class from inheriting from a sealed class or interface, since if a ‘when’ clause were used among the sealed class’s alternatives, such a class would not match any branch of the ‘when’. I think that Kotlin’s current design unnecessarily constrains code that can be written, by preventing abstract subclasses of sealed types, when it is only really necessary to prevent non-abstract subclasses of sealed types.
#2: With Kotlin’s current design, if I were to declare a class like “Abstract2” as in the above, there would be no way to prevent it from being treated as one of the valid sealed alternatives (other than to move it to another package). This is because, unlike Java, in Kotlin, a sealed class does not list its specific allowed subclasses (in Java a sealed class can have a ‘permits’ clause) and also there is no way to indicate that a subclass of a sealed class in the same package should not be considered one of the alternatives (this is done using the ‘non-sealed’ keyword in Java). Because there is no equivalent to “non-sealed” in Kotlin, any ‘when’ clause involving class S would have to have a branch for ‘Abstract2’ even though I probably only really wanted to have to have a branch for S1 and S2, and intended for any subclass of Abstract2 to inherit from S1 or S2 eventually.
So my proposals for Kotlin are:
P1: It should be allowed for an abstract class to inherit from a sealed class in a different package.
P2: It should be an error for a non-abstract class to inherit (directly or indirectly) from a sealed class in a different package unless the class also inherits (directly or indirectly) from one (or more?) of the sealed class’s alternatives.
P3: Add a new keyword like Java’s “non-sealed”, such that if an abstract class in the same package as a sealed class inherits from the sealed class, and that class has the non-sealed keyword, then that class should not be considered to be one of the exhaustive alternatives for that sealed class (in a ‘when’ clause for instance). Due to P2, it will still be required that any non-abstract subclass of that abstract class will inherit one (or more?) of the sealed class’s alternatives that aren’t marked with non-sealed.
Comments? Are there any inconsistencies or holes here?