Kotlin's Type System is (Also) Unsound

Elad Kinsbruner,Hila Peleg,Shachar Itzhaky
2024-08-20
Abstract:Soundness of a type system is a fundemental property that guarantees that no operation that is not supported by a value will be performed on that value at run time. A type checker for a sound type system is expected to issue a warning on every type error. While soundness is a desirable property for many practical applications, in 2016, Amin and Tate presented the first unsoundness proof for two major industry languages: Java and Scala. This proof relied on use-site variance and implicit null values. We present an unsoundness proof for Kotlin, another emerging industry language, which relies on a previously unknown unsound combination of language features. Kotlin does not have implicit null values, meaning that the proof by Amin and Tate would not work for Kotlin. Our new proof, which is an infringing code snippet, utilizes Kotlin's \emph{declaration-site} variance specification and does not require implicit null values. We present this counterexample to soundness in full along with detailed explanations of every step. Finally, we present a thorough discussion on precisely which language features cause this issue, as well as how Kotlin's compiler can be patched to fix it.
Programming Languages,Software Engineering
What problem does this paper attempt to address?
### Problems the Paper Attempts to Solve This paper attempts to demonstrate that the Kotlin type system is also unsound. Specifically, the authors show how to construct a counterexample by exploiting a new unsound combination of Kotlin's language features, particularly declaration-site variance and type erasure, to prove that the Kotlin type system cannot guarantee type safety in certain situations. ### Background and Motivation The soundness of a type system is a fundamental property that ensures a program will not perform unsupported operations on values at runtime. If a type system is sound, the compiler will issue warnings for every type error. However, in 2016, Amin and Tate proved that the type systems of two major industrial languages—Java and Scala—are unsound, relying on the use of use-site variance and implicit null values. Kotlin is another emerging industrial language. Although it does not have implicit null values, the authors have discovered a new unsound combination that exploits Kotlin's declaration-site variance feature. This new unsound combination differs from those in Java and Scala in that it does not require implicit null values. ### Main Contributions 1. **New Unsound Combination**: The authors present a previously unknown combination of unsound language features and provide a new counterexample to demonstrate the unsoundness of the Kotlin type system. 2. **Detailed Analysis**: The authors provide a detailed analysis of the causes and implications of this result, comparing it with other popular industrial languages. 3. **Design and User Recommendations**: The paper discusses how to avoid this issue from a language design perspective and how users can prevent this problem in their own code. 4. **Compiler Fix Suggestions**: The authors propose suggestions for fixing the Kotlin compiler to help identify such potentially unsafe code. ### Experiments and Results The authors demonstrate, through specific code examples, how to construct an unsound type conversion by exploiting Kotlin's declaration-site variance and type erasure. This example code can successfully compile without any warnings but will result in illegal operations at runtime. ### Conclusion One of the design goals of a type system is to protect developers from performing illegal operations on values. When a type system is unsound, it cannot guarantee that a type-correct program will not cause type errors at runtime, potentially leading to unexpected crashes. This paper demonstrates the unsoundness of the Kotlin type system through a new counterexample and discusses how to address this issue from both language design and compiler perspectives.