![\"Иллюстрация](\"/assets/illustrations/mascot-hero-2017-ctfe-roof-identity-v2.png\")
Симптом обычно выглядит безобидно: функция вызывается как обычная, но сборка внезапно занимает минуты, потребляет много памяти или падает на большом входе. Другой вариант — программа запускается дольше, потому что вычисление, которое можно было выполнить один раз, осталось в runtime. Цена ошибки двойная. Разработчик теряет время на сборке и получает неясную границу между кодом программы и кодом компилятора.
\nCTFE в D решает только одну задачу: выполняет функцию во время компиляции, когда контекст требует значения уже на этом этапе. Результат затем используется как готовая константа, размер массива, аргумент шаблона или строка для mixin. Это не отдельный язык и не гарантия, что любой вызов станет compile-time. Функция должна оставаться допустимой и для обычного выполнения, а входы должны быть известны компилятору.
Хороший кандидат для CTFE принимает небольшие фиксированные данные и возвращает компактный результат. Так можно заранее построить таблицу, разобрать короткую схему, вычислить маску или проверить инвариант. Плохой кандидат читает сеть, текущее время, состояние операционной системы или большой внешний файл. Такие значения принадлежат окружению запуска. Их нужно получать явно в runtime либо отдельным шагом подготовки до компиляции.
\nНовый движок CTFE исторически решал проблему стоимости старого интерпретатора. Старый подход создавал объекты AST для большого числа промежуточных выражений. Длинный цикл или сложное регулярное выражение могли породить огромное количество узлов и занять гигабайты памяти. Идея нового подхода — сначала скомпилировать функцию в промежуточное представление, а затем исполнять его специализированным интерпретатором. Это уменьшает накладные расходы представления, но не отменяет стоимость самого вычисления и не делает любой код подходящим для CTFE.
\nПоэтому вопрос звучит не так: «умеет ли новый движок выполнить эту функцию?». Практический вопрос другой: «какие входы известны, насколько велик результат, сколько стоит вычисление в сборке и что остаётся runtime?». Ответ должен быть виден из кода и проверяться обычной сборкой.
\nВ D CTFE срабатывает в контексте, где требуется compile-time значение. Вызов той же функции в обычном выражении может выполниться при запуске. Разница определяется местом использования, а не специальным именем функции.
\nstring[] buildRoutes()\n{\n return [\"/\", \"/catalog\", \"/checkout\"];\n}\n\nenum string[] routes = buildRoutes();\n\nstatic assert(routes.length == 3);\n\nvoid main()\n{\n import std.stdio : writeln;\n writeln(routes);\n}Здесь и входы, и результат известны из исходника. Инициализатор enum требует значения на этапе компиляции, поэтому компилятор пытается выполнить buildRoutes через CTFE. static assert проверяет свойство результата тоже на этапе компиляции. В main программа читает уже сформированный массив; она не строит маршруты заново.
Учебный пример не доказывает ускорение конкретного приложения. Он показывает только границу выполнения. Реальный выигрыш нужно измерять на своём проекте: сравнить время сборки, размер бинарника и работу runtime на одинаковом входе.
\nКомпилятор не может считать сетевой ответ или текущее время стабильным значением исходного кода. Даже чтение файла окружения меняет результат между машинами и сборками. Если функция зависит от такого состояния, она перестаёт быть хорошим compile-time контрактом. Скрывать зависимость нельзя: получится сборка, которая зависит от рабочей директории, переменной окружения или случайного файла.
\nУ CTFE есть и более тонкая граница. D требует, чтобы функция, выполняемая на этапе компиляции, могла быть скомпилирована для runtime. Поэтому нельзя строить функцию только вокруг compile-time поведения, которое не имеет корректного runtime-представления. Когда нужна генерация кода из строкового шаблона, отделите шаблонный интерфейс от функции, которую можно вызвать обычным способом.
\nПсевдопеременная __ctfe позволяет выбрать отдельную ветку для compile-time, если операция запрещена в CTFE и для runtime есть другой путь. Используйте её редко. Она делает два режима выполнения явными, но также удваивает число путей, которые нужно поддерживать и проверять.
| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| Сборка резко замедлилась | Большой цикл выполняется через CTFE | Собрать минимальный пример и сравнить время с runtime-вызовом | Уменьшить вход, разбить вычисление или вернуть его в runtime |
| Компилятор расходует много памяти | Сложное вычисление создаёт большое промежуточное состояние | Проверить размер входа и воспроизвести сбой на изолированном вызове | Сократить таблицу, изменить алгоритм или вынести подготовку в отдельный генератор |
| Результат различается на машинах | CTFE читает окружение, время или файл | Повторить сборку с чистым окружением и сравнить входы | Передавать данные явно и оставить зависимое от среды действие в runtime |
| В runtime вычисление всё ещё выполняется | Вызов стоит в обычном выражении, а не в compile-time-контексте | Добавить static assert или использовать значение в enum | Перенести вызов в контекст, где требуется compile-time значение |
| Секрет попал в бинарник | Значение встроилось в результат сборки | Проверить артефакт и строковые константы | Не передавать секрет в CTFE; читать его при запуске из защищённого источника |
Сравнивайте три стоимости. Первая — время компиляции. Вторая — память компилятора и размер получившегося бинарника. Третья — время запуска и частота повторения вычисления. CTFE оправдан, если одно вычисление на сборку заменяет много одинаковых вычислений при запуске и сборка остаётся предсказуемой. Если сборка выполняется для каждого небольшого изменения, даже умеренная таблица может сделать цикл разработки хуже.
\nРазмер результата тоже важен. CTFE может ускорить запуск, но встроить в бинарник большой массив. Это влияет на загрузку, кэш и поставку артефакта. Нельзя объявлять оптимизацию успешной только потому, что runtime больше не вызывает функцию. Нужен баланс между стоимостью сборки и стоимостью использования.
\nОтдельно проверьте повторяемость. Одинаковый исходный код и одинаковые входы должны давать одинаковый результат. Если результат зависит от локали, платформенного размера типа или implementation-defined поведения, зафиксируйте это ограничение или не переносите вычисление в CTFE.
\nenum, размер статического массива, static if, static foreach, static assert или другой поддерживаемый контекст.static assert для главного свойства результата. Проверка должна ломать сборку при неверном значении.Поддерживаемые операции и эффективность CTFE зависят от версии компилятора и конкретного кода. Историческое описание NewCTFE объясняет архитектурное направление, но не является обещанием одинакового поведения в любой современной сборке. Проверяйте фактическую версию DMD, LDC или другого компилятора в своём проекте.
\nCTFE не изолирует секреты. Если пароль или ключ известен на этапе компиляции, его можно извлечь из исходников, промежуточных данных или бинарника. Не используйте compile-time вычисления как механизм защиты.
\nCTFE также не заменяет генератор, если входом служит большой внешний документ. Генератор может иметь собственный кэш, отчёт об ошибках и понятный артефакт. Это другая граница ответственности. Не прячьте её внутри компилятора ради короткого вызова функции.
\nПеренос готов, если выполнены все четыре условия: входы перечислены и не зависят от скрытого окружения; static assert проверяет ключевое свойство; сборка проходит на целевой версии компилятора с зафиксированным ресурсным профилем; runtime использует готовое значение и не повторяет вычисление. Для отрицательного пути должен существовать пример, который остаётся runtime-кодом или явно останавливается на границе CTFE.
Если хотя бы одно условие не выполнено, статус должен быть «не готово», даже когда отдельный пример компилируется. CTFE полезен не потому, что компилятор способен выполнить функцию, а потому, что команда понимает, где это выполнение происходит, сколько оно стоит и почему результат можно безопасно использовать.
\n