Почему все функции в Android не могут быть Inline

Ёпта, слушай, давай про эти ваши inline-функции в Kotlin разберёмся, а то народ путается, какого хуя они не везде работают. Ситуация, блядь, как с машиной: вроде турбина есть, а ехать не на всём бензине можно, иначе движок накроется медным тазом.

Вот смотри, inline — это по сути волшебная палочка для скорости. Вместо того чтобы честно вызывать функцию, компилятор тупо копирует её код прямо на место вызова. Представь, что ты вместо того чтобы позвать друга помочь диван передвинуть, сам становишься этим другом на пять секунд. Эффективно? Ебать! Но не всегда применимо.

Теперь, почему не всё можно так вот inline'нуть? Причины есть, и они железобетонные, чувак.

1. Рекурсивные функции. Ну тут вообще пиздец, если подумать. Представь, функция вызывает сама себя. Ты её inline'нул в точке вызова. Она скопировалась, и внутри её кода... снова вызов себя. И этот вызов тоже надо inline'нуть! Это ж бесконечная матрёшка, ёпта! Компилятор с ума сойдёт, код будет расти как на дрожжах, в итоге получится овердохуища текста, а программа — сосалка по памяти. Поэтому рекурсию так не оптимизируют, тут без вариантов.

2. Функции с reified типами. А вот это, наоборот, требует inline. Смотри, в обычной жизни дженерик-тип в рантайме стирается. То есть внутри функции ты не можешь спросить: «А ты кто по жизни, T? String или Int?». Но если объявить тип как reified T и сделать функцию inline, то магия случается. Поскольку код встраивается, компилятор знает конкретный тип на момент компиляции и может его подставить. Без inline это просто невозможно, так что это не ограничение, а обязательное условие. Сам от себя охуеешь, когда первый раз используешь.

3. Функции высокого порядка (с лямбдами). Вот это их родная стихия, блядь! Обычно, когда ты передаёшь лямбду в обычную функцию, под капотом создаётся анонимный класс — это накладные расходы, целый объект. А если функцию пометить inline, то и тело функции, и код лямбды встроятся прямо на место вызова. Никаких лишних объектов, чистая скорость. Главное, не делать это с огромными лямбдами, а то размер скомпилированного кода раздует так, что пипец.

4. Public API функции. А вот это хитрая жопа. Смотри, ты написал библиотеку, выложил её версию 1.0 с inline-функцией. Потом решил её поменять внутри. Поскольку inline-функция не вызывается, а встраивается, её код уже стал частью скомпилированного байт-кода тех, кто её использует. Если они слинкуются на новую версию библиотеки, но старый скомпилированный код останется со старой вставкой — будет тебе, чувак, конфликт и падение. доверия ебать ноль к такой бинарной совместимости. Поэтому для публичного API часто лучше не inline, чтобы можно было безопасно обновлять реализацию.

Ну и пример, чтобы вообще всё встало на свои места, вот:

inline fun <reified T> parseJson(json: String): T { 
    // Требует inline для reified T
    return Gson().fromJson(json, T::class.java)
}

Видишь? reified T. Мы внутри хотим получить T::class.java. В обычной функции это ёперный театр, тип T стёрт. Но так как функция inline, когда ты вызовешь parseJson<String>(myJson), компилятор подставит на место вызова код, где вместо T будет конкретно String::class.java. Удобно? Ебать копать! Но только если функция inline, иначе — хуй с горы, не скомпилируется.

Короче, инструмент охуенный, но как молоток: гвозди забивать — идеально, а вот для шурупов уже хуёво. Нужно просто понимать, где что применять, и не пытаться inline'нуть всё подряд, а то получится пиздопроебибна архитектура.