Имеет ли смысл объявлять функцию как inline, если она не принимает лямбда-выражения

Отличный вопрос, который затрагивает тонкости оптимизации в Kotlin. Прямой и короткий ответ: да, имеет, но смысл меняется и становится более узким и ситуативным.

Когда функция не принимает лямбда-выражения, классическая мотивация для inline — избежать создания объектов Function — отпадает. Однако, ключевое слово inline продолжает влиять на поведение кода, и его использование может быть оправдано в следующих сценариях.

1. Устранение накладных расходов на вызов функции (Performance Critical Code)

Это первоначальная цель inline в таких языках, как C++. В Kotlin вызов обычной функции (не inline) связан с определенными издержками: создание стека вызова, передача аргументов, переход к месту выполнения. Для подавляющего большинства функций эти издержки ничтожны. Но для функций, вызываемых в "горячих" участках кода (hot paths) — например, внутри глубоких циклов, выполняющихся тысячи или миллионы раз, — их устранение может дать измеримый прирост производительности.

// Небольшая функция, часто вызываемая в цикле
inline fun calculateOffset(x: Int, y: Int): Int = x * 10 + y

fun processLargeDataSet(data: List<Pair<Int, Int>>) {
    var total = 0
    for ((a, b) in data) {
        // Здесь тело calculateOffset будет "вшито" прямо в цикл,
        // избегая вызова функции для каждой итерации.
        total += calculateOffset(a, b)
    }
}

После компиляции код будет эквивалентен total += a * 10 + b, без промежуточного вызова.

2. Работа с типами с реифицированными (reified) параметрами

Это самый частый и прагматичный случай для inline-функций без лямбд. В обычном коде из-за стирания типов (type erasure) информация о generic-параметрах (T) недоступна во время выполнения. Ключевое слово reified может использоваться только вместе с inline.

// Эта функция НЕ может существовать без inline
inline fun <reified T> checkTypeAtRuntime(item: Any): Boolean {
    // Мы можем обратиться к классу T во время выполнения!
    return item is T
}

// Использование
val isString = checkTypeAtRuntime<String>("Hello") // true
val isInt = checkTypeAtRuntime<Int>("Hello") // false

Здесь inline позволяет компилятору подставить конкретный класс (String, Int) в точку вызова, делая проверку is возможной.

3. Контроль над потоком выполнения (Non-local returns)

Хотя в вопросе упомянуты функции без лямбд, важно понимать, что inline позволяет лямбде, переданной в такую функцию, совершить нелокальный возврат (вернуться из внешней функции). Это основа работы стандартных функций типа run, let, with. Даже если ваша текущая функция не использует лямбды сейчас, вы можете добавить их позже, и модификатор inline уже будет на месте.

Когда НЕ стоит использовать inline для функций без лямбд?

• Крупные функции: Инлайнинг большой функции приведет к "раздуванию" байт-кода в каждом месте вызова. Компилятор может проигнорировать inline для больших функций, но лучше не полагаться на это.
• Рекурсивные функции: Их нельзя инлайнить (прямо или косвенно).
• Функции с сложным потоком выполнения: Виртуальные функции (открытые open) или функции-переопределения интерфейсов не могут быть инлайн, так как точная реализация неизвестна на этапе компиляции.
• Преждевременная оптимизация: Не стоит помечать как inline все подряд. Сначала пишите читаемый код, затем профилируйте и оптимизируйте только критические участки.

Итог

Для функции, не принимающей лямбда-выражения, объявление как inline имеет два основных смысла:

1. Производительность в "горячем" коде: Устранение накладных расходов на вызов функции в критических по производительности участках (микрооптимизация).
2. Использование reified типов: Это наиболее веская причина. Если вам нужна информация о generic-типе во время выполнения, inline с reified — единственный легальный способ в Kotlin.

Таким образом, хотя основная "громкая" фича inline — это оптимизация лямбд, его utility шире. Решение должно быть обоснованным: используйте inline для reified типов или для крошечных функций в узких местах производительности, подтвержденных профилированием. Во всех остальных случаях для обычных функций он излишен и может иметь негативные последствия.