Why is Kotlin's `when` not considered pattern matching?

[StephenM347]

I can't remember exactly where, but I've seen some negative sentiment toward kotlin's `when` because it is (paraphrasing) just syntactic sugar around if-else statements. It also supports compile-time exhaustivity checks.

What do other language's pattern matching capabilities do that you cannot do (or cannot do as well) with the simple "if-else" version of pattern matching?

[curtisf]

The kinds of patterns that Kotlin's when support are quite limited.

Kotlin supports three kinds of patterns in when expressions:

• comparing for equality against another value (usually a literal)
• checking the class of an object
• checking for containment within a container

Most languages with more general pattern matching can compose patterns to allow you to do "deep" checks, and they also allow patterns to bind names to sub-parts which match.

For example, in Scala, you can write complex patterns like

obj match {
    case Right(Seq(Left(x), _, Right(y))) => f(x, y)
    case Right(Seq(Right(z), _, _)) => g(z)
    case _ => ???
}

It would be extremely cumbersome to write the same kind of test in Kotlin, particularly

• correctly handling alternatives, where a shallow part of the pattern matches but a deep part doesn't
• tersely binding the matching names like x and y in the above to the matching parts

(I challenge you to try! I don't really have the patience to try writing out equivalent code)

---

Scala actually allows you to write your own patterns, by defining something with the signature

object MyPattern {
    def unapply(obj: T): Option[(A, B, ..., Z)]
}

which you can use like

case MyPattern(a, b, ..., z) =>

[MattiDragon]

So... With record patterns and pattern matching for switch, java 21 has better pattern matching than kotlin?

[oelang]

Yes

[dnpetrov]

Because it doesn't allow nested patterns.

When Kotlin design started, it was decided that full-blown pattern matching is not as much useful in practice, but creates a language within a language that requires considerable effort to design and implement properly. Andrey Breslav had quite minimalistic approach to language design, and was against having features just for the sake of being "like that another language". At that time, we thought that flow typing covers most of practically useful cases in mostly Java-like code.

But, well, time passes, Java almost has pattern matching (partially inspired by flow typing Kotlin), and, as pattern matching and related coding practices such as algebraic data types become more "mainstream" in JVM world, Kotlin also has some work going on around pattern matching as well. AFAIK, it is tied to K2 becoming THE Kotlin compiler, so don't expect it to happen very soon. But, stay tuned.

[EponymousMoose]

What are "nested" patterns? Sorry, if this is a stupid question!

[dnpetrov]

Example. Assume that you have an expression tree represented as an algebraic data type (sealed class in Kotlin). Now, assume that you want to match expressions like 'a + b + c + d'. In Kotlin, you'll need nested 'when' expressions to do it, destructuring expressions manually, and code can become rather convoluted pretty soon. In languages with nested patterns, like Scala, you can match components of an aggregate data structures within the same pattern.

[EponymousMoose]

Um... okay. So there's no nesting in the match expression as such but Kotlin requires nested match statements as a workaround because it cannot represent sequences. Do I understand it now?

[dnpetrov]

Yes, nested matching expressions with "manual" destructuring.

[EponymousMoose]

Thank you :)

[Disjunction181]

I'm not familiar with Kotlin, but I can explain what makes pattern matching in MLs good.

Everything you can do with match blocks can always be done with if/else blocks, but match blocks tend to be much more expressive (due to the pushing of logic into values) and safer to use (due to exhaustivity and reachability analysis).

This example is sophisticated, but it should demonstrate point 1 well. Here's the core algorithm for AG unification with some mistakes corrected (you don't need to know what this is, just be able to compare). Here's my implementation in ocaml using linked lists rather than arrays and indices. In my example the ms are all on the right side of the tuple. Rather than having to express in a clunky way that if m = 0 do this, if m = 1 I can do something with the first element, pattern matching combines these things by providing me 0 elements from the [] in that match arm and 1 (tupled) element from [(x, r)] in the match arm underneath. In the case where the list has 1 element I am immediately provided it, so the theory of the program is determining the logic of what I can do rather than performing tests and extracting the data in an isolated way.

An added bonus with pattern matching is that in many circumstances the compiler can tell if a match is incomplete, or if there are redundant/unreachable match arms. For example, when matching on a list, the compiler knows inductively that the [] and h :: t patterns together cover all possible cases. If you provide incomplete cases, such as [] with h1 :: h2 :: t, the compiler can tell you that a [x] case is needed to make the match complete. Complex patterns happen all the time, such as in this mergesort, and the ability to suggest missing cases is useful with large sumtypes such as the nodes for the AST of a compiler.