I didn’t miss destructuring pattern match

Kotlin doesn’t have destructuring pattern match & language support for tuples. A limited form of destructuring can be used in for loops and assignments. The when expression is an alternative conditional expression that doesn’t do destructuring.

I was surprised to find that I didn’t really miss destructuring. Without tuples you have to use data classes with named fields. The flow-sensitive typing then works rather well where destructuring would be necessary in a language where the type system is not flow-sensitive. For example:

sealed class Result<out T> {
   class Success<T>(val value: T) : Result<T>()
   class Failure(val exception: Throwable): Result<Any>()
}

...

val e : Result<String> = doSomething()
if (e is Result.Success<String>) {
    // e is known to be a Result.Success<String> and
    // can be used as such without a downcast
    println(e.value)
}

Sealed classes cannot be data classes

An algebraic data type cannot be be a data class, so you have to write equals, hashCode, etc. yourself. This is a surprising omission, since I always want an algebraic data type to be a value type. The Kotlin developers say that this will be fixed after version 1.0 is released.

Functions are not quite first-class objects

There’s a difference between f1 and f2 below:

val f1 = {i:Int -> i+1}
fun f2(i:Int) = i + 1

Code can refer to the value of f1 directly, but must use the “::” operator to obtain a reference to f2:

val f = ::f2

Null safe operators push me to write more extension functions

The null safe operators (?. and ?:) only help when dereferencing a nullable reference. When you have a nullable reference and want to pass a value (if it exists) to a function as a parameter, you have to use the awkward construct:

nullableThing?.let{ thing -> fn(thing, other, parameters) }

I find myself refactoring my functions to extension functions to reduce the syntactic noise, letting me rewrite the code above as:

nullableThing?.fn(other, parameters)

Is that a good thing? I’m not sure. Sometimes it feels a little forced.

Companion objects

Kotlin borrows the concept of companion objects from Scala. Why can’t classes be objects? Perhaps it’s a limitation of the JVM but compared to, say, Python, it feels clunky.

Lack of polymorphism

Operators and the for loop are syntactic sugar that desugar to method calls. The methods are invoked statically and structurally — the target does not need to implement an interface that defines the method.

For example, a + b desugars to a.add(b). However, there’s no way to write a generic function that sums its parameters, because add is not defined on an interface that can be used as an upper bound.

There’s no way to define the following function for any type that has an add operator method.

fun <T> sum(first: T, second: T) : T = first + second

You would have to define overloads for different types, but then wouldn’t be able to call sum within a generic function.

fun sum(first: Int, second: Int) = first + second
fun sum(first: Long, second: Long) = first + second
fun sum(first: Double, second: Double)= first + second
fun sub(first: Matrix<Double>, second: Matrix<Double>)= first + second
fun sum(first: Money, second: Money)= first + second
...

That kind of duplication is what generics are meant to avoid!

Extension methods are also statically bound. That means you cannot write a generic function that calls an extension method on the value of a type parameter.

For example, the standard library defines the same extension methods on unrelated types — forEach, map, flatMap, fold, etc. But there is no concept of, for example, “mappable” or “foldable”. Nor is there a way of defining such a concept and applying it to existing types to allow you to write generic functions over unrelated types. Kotlin doesn’t have higher kinded types that would let you express this kind of generic function or type classes that would let you add polymorphism without modifying existing type definitions.

Compared to Rust’s traits, which support extension methods, operator overloading, type classes for parametric polymorphism, and interfaces for subtype polymorphism, Kotlin’s monomorphic extension methods and operator overloading are quite limited and do not help refactor duplicated logic.

However, for typical monomorphic, procedural Java code this is probably not an issue.

Optionality is a Special Case

Kotlin’s support for nullable types is implemented by a special case in the type system and special case operators that only apply to nullable references. The operators do not desugar to methods that can be implemented for other types. For example, optionalThing?.foo can be considered a map of the function {thing -> thing.foo} over the option optionalThing. If foo itself is nullable, then it can be considered a flatMap. But the expressions do not desugar to map and flatMap And if you want to map or flatMap a function, you have to use a different syntax: optionalThing?.let(theFunction).

For typical Java code, which is monomorphic and uses null references with wild abandon, language support for nullability is invaluable. But I would find it more convenient if it could be used polymorphically, or if Kotlin used a common naming convention for optional and other functor types.

Null safety is not enforced when you interop with Java code. And you do that a lot. Kotlin doesn’t have many libraries or much of a runtime and makes it easy to call existing Java libraries directly. Kotlin expects you to know what you’re doing with respect to null references when calling Java code, and doesn’t force you to treat every value returned from Java as nullable. As a result, null safety is a bit of an illusion in a lot of our Kotlin code and it has come back to bite us.