Почему в Kotlin нет примитивных типов?

Краткий ответ

Kotlin действительно имеет примитивные типы, но они "спрятаны" за семантикой объектов на уровне языка программирования, в то время как на уровне байткода JVM они существуют как настоящие примитивы для обеспечения производительности.

Это фундаментальный дизайн-компромисс Kotlin: предоставить разработчику удобство единой объектной модели (где всё — объект), но при компиляции автоматически оптимизировать код, используя примитивные типы JVM там, где это возможно для максимальной производительности. Это достигается благодаря механизму inline-классов (ранее экспериментальных, теперь стабильных с Kotlin 1.5) и интеллектуальной работе компилятора.

Подробное объяснение архитектуры

1. Унификация типов на уровне языка (Обёртка для разработчика)

В исходном коде Kotlin вы всегда работаете с типами как с объектами. Например, Int, Double, Boolean — это классы. У них есть методы, их можно использовать в обобщённых (generic) конструкциях. Это решает несколько проблем Java:

• Единообразие: Нет разницы между int и Integer, нет необходимости в автобоксинге/распаковке вручную.
• Null-безопасность: Объявление Int? сразу создаёт nullable-тип, который на уровне JVM будет представлен классом-обёрткой (например, java.lang.Integer).
• Функции-расширения: Вы можете вызывать методы у "примитивов": 42.toString(), 3.14.roundToInt().

// В Kotlin-коде всё выглядит как работа с объектами
val number: Int = 10 // Выглядит как объект
val nullableNumber: Int? = null // Nullable версия — это уже точно объект-обёртка
val doubled = number * 2 // Арифметические операции
val stringRepr = number.toString() // Вызов метода

2. Оптимизация на уровне байткода (Реальность для JVM)

Компилятор Kotlin (Kotlin/JVM) крайне интеллектуален и проводит сглаживание типов (type inference and smashing). Когда это возможно, он использует настоящие примитивы JVM (int, double, boolean и т.д.).

Когда Kotlin использует примитивы JVM:

• Для локальных переменных и не-nullable свойств.
• В массивах специализированных типов, например IntArray (который компилируется в int[]), в отличие от Array<Int> (который становится Integer[]).
• В арифметических операциях и вычислениях.

Когда Kotlin вынужден использовать классы-обёртки:

• Когда тип объявлен как nullable (Int?).
• Когда тип используется в generic-коллекциях (например, List<Int> — из-за стирания типов в JVM).
• При передаче "примитивного" типа в функцию, ожидающую параметр типа Any или Comparable<Int>.

fun example() {
    val primitiveLike: Int = 100 // Скорее всего, станет 'int' в байткоде
    val boxed: Int? = 100 // Станет 'java.lang.Integer', так как может быть null
    val list: List<Int> = listOf(1, 2, 3) // Элементы будут boxed (Integer)
    val array: IntArray = intArrayOf(1, 2, 3) // Останется примитивным массивом int[]
}

3. Ключевая роль Inline-классов (Value-классы)

С версии Kotlin 1.5 стабильной стала функция inline-классов (помечаются value). Это механизм, позволяющий создавать обёртки над примитивными типами без накладных расходов на этапе выполнения.

// Объявление value-класса
@JvmInline
value class Password(private val s: String) // На уровне байткода будет использоваться String

fun login(pwd: Password) { ... }

// Использование
login(Password("secret")) // В runtime передаётся строка "secret", не объект Password

Именно так Kotlin и поступает со своими "примитивами" — Int, Double и другие по сути являются высокооптимизированными inline-классами от компилятора.

Сравнение с Java

Вывод

Таким образом, утверждение "в Kotlin нет примитивных типов" верно только на уровне абстракции языка. Для программиста их действительно нет — есть единая, чистая и безопасная объектная модель. Однако виртуальная машина JVM работает с примитивами, и компилятор Kotlin генерирует максимально эффективный байткод, широко их используя. Это "лучшее из двух миров": безопасность и выразительность высокоуровневого языка сочетаются с производительностью низкоуровневых примитивов. Такой подход избавляет разработчика от рутинных решений о выборе между int и Integer, перекладывая эту ответственность на интеллектуальный компилятор.