Ответ.

История вопроса:

В JVM во время исполнения отсутствует информация о параметрах обобщения (type erasure). Kotlin предложил механизм reified generic-параметров для inline-функций, чтобы реализовать доступ к информации о типе T во время выполнения без костылей вроде передачи Class<T>. Это одно из самых мощных средств языка Kotlin.

Проблема:

Требуется написать функцию, которая принимает некое значение типа T (generic) и в зависимости от типа параметра выполнять разные действия, без явной передачи java.lang.Class и без рефлексии на Java-лад. Classical type erasure не даёт узнать тип T во время исполнения.

Решение:

В Kotlin для inline-функций допускается объявлять generic-параметры с модификатором reified, что позволяет "запечатлеть" тип T внутри тела функции, работать с ним как с обычным типом, делать type-checks и создавать экземпляры через reflection.

Пример кода:

inline fun <reified T> isOfType(value: Any): Boolean {
    return value is T
}

isOfType<String>(123) // false
isOfType<Int>(123) // true

Ключевые особенности:

• Доступ к типу T внутри функции на этапе выполнения
• Возможность вызывать операции типа value is T, T::class, T::class.java
• Работает только для inline-функций

Вопросы с подвохом.

Можно ли использовать reified вне inline-функций?

Нет! Только inline-функции (и inline-ленивые property) могут иметь reified generic-параметр. Причина — подстановка кода на месте вызова, только так можно "подставить" конкретный тип вместо T.

Пример кода:

// Ошибка компиляции:
fun <reified T> errorFun() { }

// Верный вариант:
inline fun <reified T> okFun() { }

Можно ли получить Class<T> внутри inline reified-функции?

Да! Для этого достаточно написать T::class.java или T::class. Это крайне удобно для написания generic-фабрик, парсеров и работы с reflection API.

Пример кода:

inline fun <reified T> printType() {
    println(T::class.java)
}

printType<String>() // class java.lang.String

Можно ли создавать экземпляры типа T через конструктор в reified-функции?

Частично. Можно использовать рефлексию, но напрямую new T() как в C++ или C# не получится:

inline fun <reified T : Any> makeInstance(): T? {
    return T::class.constructors.firstOrNull()?.call()
}

Но этот подход требует наличия конструктора без параметров у T.

Типовые ошибки и анти-паттерны

• Переиспользование reified слишком часто вместо явной передачи типа (например, везде, где нужно просто Class<T>)
• Использование reified не для inline-функций
• Ожидание, что можно всегда инстанцировать T, не обеспечив подходящего конструктора

Пример из жизни

Негативный кейс

Функция с reified, вызывающая среди кода тяжёлую reflection-операцию:

inline fun <reified T> foo(): T? = T::class.constructors.firstOrNull()?.call()

Плюсы:

• Универсально, удобно для тестов

Минусы:

• Медленно
• Нет контроля над ошибками конструктора, сложно дебажить

Позитивный кейс

Использование reified для универсального type-check или safeCast:

inline fun <reified T> safeCast(value: Any?): T? = value as? T

Плюсы:

• Лаконично
• Безопасно (as?)
• Нет overhead по производительности

Минусы:

• Поддерживается только в inline-функциях