А можно примеры таких проектов? Линукс? К тому же это не означает, что они не сыскали бы ещё большую популярность, если переехали на гитхаб/гитлаб.

Боюсь, такая дискуссия далеко нас заведет. Предлагаю здесь ее свернуть :)

Да, это уже оффтоп)

> Новая аудитория нужна чтобы проект не загнулся, если со старой что-то станет.

"Новая аудитория" может так же запросто "загнуть" проект. Есть даже какая-то пословица на эту тему... про то, что новый друг полезнее, чем два старых... нет, там было как-то не так... ;)

> А можно примеры таких проектов? Линукс?

И другие зрелые opensource OS — тоже, насколько я помню.  Да и другие активно развивающиеся "старые" проекты.
Но, вообще, да: https://t.me/CompilerDev/68231 , извините.

"Новые песни пишут те, у кого старые плохие" :)

Не так давно опубликовали
https://habr.com/ru/company/jugru/blog/494986/

Ещё одна статья от автора вышеидущего доклада
https://habr.com/ru/company/samsung/blog/505850/

Интересный доклад, спасибо!

Но вот этот абзац вызывает сомнения:
«Tail Call тоже классическая оптимизация: минимизирует оверхед, который создается за счет создания стекового фрейма; преобразует call, который находится в конце функции, просто в инструкцию jump, то есть в передачу управления на следующую функцию. Оптимизация выполняется в бэкенде, потому что не для всех архитектур её возможно выполнить. Есть архитектуры, где адрес передачи управления инструкции jump кодируется в меньшее количество бит, чем call, и не все адреса в jump удается представить.»

Оптимизация для хвостовой рекурсии слишком выгодная вещь, чтобы опускать руки из-за проблем с jump.

Для таких случаев (если адрес не помещается в литерал для jump) мне известен только способ перехода с трамплинами, но это несколько переходов нужно сделать

А можно ведь и call обойтись? Убрать старый фрейм и адрес возврата перед вызовом.

кажется это не будет быстрее

Это не хвостовая рекурсия, а замена хвостового вызова на прыжок.

То есть, вызова другой функции.

А разве не в этом суть оптимизации хвостовой рекурсии?

Если вопрос стоит ребром — получим stack overflow или нет, то даже медленно будет хорошо :)

тогда с трамлпинами точно заработает, и стэк не надо трогать

Разница в том, вызов какой функции мы заменяем. Если вызов себя, то это, очевидно, выгодно настолько, что мы делаем замену всегда, иначе надо считать, выгодно ли вызвать другую функцию или лучше прыгнуть. Во втором случае, ктсати, ещё регистры надо не забыть почистить (если мы не имеет доступа к телу функции, а ABI гарантирует, что эти регистры можно использовать для локальных переменных).

А вдруг эти "хвостовые" трамплины, в свою очередь, чрезмерно удлинят расстояния для прыжков по обычным if/while? Тогда придется делать дополнительные трамплины... :)

все равно безопаснее, чем ковырять стэк)