When statement ON SEALED INTERFACE SUBJECT always considered exhaustive

[jorrit200]

warning: I originally described this issue as regarding when statements in general, but it only affects when statement that have a sealed interface as subject.

The LSP considers every when statement I have written so far to be 'exhaustive', even when this is clearly not true. Simple example below:

This holds true for when expressions as well.

I use neovim and its default kotlin_lsp config. If this issue is uncommon/hard to reproduce, I suppose I could test with other clients, but I don't really have the skills to dissect the issue any further than that. Let me know what is necessary and I will follow up.

[jorrit200]

this was on v0.253.x :| currently working to reproduce on latest release: 261.13587.0

[jorrit200]

can now confirm that the behaviour is unchanged in the newest release.

[hasanelfalakiy]

that's because your when block doesn't return a value, so else is redundant, if the when block returns a value then else must be written

[hasanelfalakiy]

try changing your code to when it returns a value, does the else redundant warning still appear?

[jorrit200]

Using a when expression instead of a statement in my provided example would probably have been clearer. But the example I provided doesn't compile without that else branch (or actually being exhaustive):

e: file://*****/TestingLspWhen/src/main/kotlin/Main.kt:11:5 'when' expression must be exhaustive. Add the 'B', 'C' branches or an 'else' branch.

So applying the quick-fix that was suggested by the LSP in the example I gave would result in uncompilable code.

Since Kotlin 1.7 a when statement on a sealed type or an enum needs to be exhaustive. https://kotlinlang.org/docs/compatibility-guide-17.html#make-when-statements-with-enum-sealed-and-boolean-subjects-exhaustive-by-default.

Also, irrespective of this compiler requirement, the else statement is not redundant here, because it changes the functionality of the code: it prints "something unknown" in 2 cases. It would have been redundant if those 2 cases were actually handled, which would make the statement exhaustive.

[jorrit200]

So I did some more testing and it turns out that this issue is related exclusively to sealed types. I should probably update this issue....

It seems to understand other potential issues with matching a sealed interface below perfectly fine:

It just thinks the case is always exhaustive when the subject is a sealed interface type.

Funnily enough, even if there are no cases at all: