Как-то я сказал своему коллеге, что в Rust имеются макросы, ему показалось, что это плохо. Раньше у меня была такая же реакция, но Rust показал мне, что макросы не обязательно плохи.  Где и как их уместно применять? Смотрите под катом. Макросы являются формой метапрограммирования: они являются кодом, который манипулирует кодом. Метапрограммирование получило плохую репутацию, потому что при их использовании нелегко уберечься от написания плохого кода. Примерами служат #define в C, который легко может взаимодействовать с кодом непредсказуемым образом, или eval в JavaScript, который увеличивают опасность инъекции кода. Многие их этих проблем могут быть решены при использовании необходимых средств, макросы же предоставляют некоторые такие средства: Для того чтобы достичь этих целей, Rust включает в себя два вида макросов -2-. Они известны под разными названиями (процедурные, декларативные, macro_rules, и т. д.), хотя я считаю, что данные имена несколько запутывают. К счастью, они не так важны, поэтому я буду называть их функциональные и атрибутные. Причиной того, что имеется два типа макросов является то, что они хорошо подходят для решения разных задач: Во всем остальном результаты их применения схожи: компилятор "стирает" макросы во время компиляции, заменяя их кодом, генерирующимся из макроса, и компилируя его с "обычным", не макро-кодом -3-. Реализация двух типов макросов сильно отличается, но мы не будет здесь глубоко в это вдаваться. Функциональный макрос может быть исполнен почти как функция. Данный вид макросов имеет ! в вызове: Зачем использовать макросы, когда можно использовать функции? Нужно помнить, что функциональные макросы ничего не имеют общего с функциями — они похожи на функции, чтобы их, макросы, было легче использовать. Поэтому вопрос стоит не в том, лучше данный тип макросов чем функции или нет, а в том, нужна ли нам возможность менять исходный код. Начнем с рассмотрения assert!, который используется для проверки того, что некоторое условие выполняется, вызывая панику (panic), если это не так. Они проверяются во время выполнения, так что же нам дает здесь метапрограммирование? Давайте посмотрим на сообщение, которое печатается, когда assert! завершается неудачно: Данное сообщение содержит в себе условие, которое мы проверяем. Другими словами, макрос создает сообщение об ошибке, которое основано на исходном коде, мы же получаем содержательное сообщение об ошибке, не вставляя его в программу вручную. Во многих языках программирования поддерживается задание форматов вывода для строк -4-. Rust не является исключением и также поддерживает задание форматов строк посредством format!. Однако по-прежнему стоит вопрос: почему мы должны использовать метапрограммирование для решения проблемы? Давайте посмотрим на println! (он внутри использует format! для обработки переданной строки) -5-. Есть много причин того, что format! реализован как макрос -6-, я же хочу подчеркнуть то, что он может разделить строку на части во время компиляции, проанализировать ее и проверить, является ли обработка переданных аргументов типо-безопасной. Мы можем изменить наш код и получить ошибку компиляции: Во многих других языках данные ошибки проявились бы во время выполнения, однако в Rust мы можем использовать макросы для того, чтобы выполнять данную проверку на этапе компиляции и генерировать производительный код для обработки формата строки без проверок времени выполнения -7-. В этом примере немного вдадимся в экосистему языка. Rust имеет пакет log, который используется как главный фронтенд логирования. Как и другие решения для логирования, он предоставляет разные уровни логирования, но, в отличие от других решений, данные уровни представляются макросами, а не функциями. Логирование показывает мощность метапрограммирования в том, как оно использует макросы file! и line!; Данные макросы дают возможность установить точное место расположения вызова функции логирования в исходном коде. Давайте посмотрим на пример. Так как log является фронтендом, добавим бэкенд, пакет flexi_logger. Эта программа напечатает: Как вы видите, наши логи содержат имена файлов и номера строк. В первом случае компилятор вставляет в исполняемые файлы необходимую информацию, которую мы можем при необходимости напечатать. Если бы мы не решали данную проблемы во время компиляции, то нам пришлось мы исследовать стек во время выполнения, что чревато ошибками и снижает производительность. Если мы заменим логирующие макросы на функции, то по-прежнему можем вызывать file! и line!: А данный код вывел бы следующее: Имя файла и номер строки бесполезны, ибо указывают на то, где была вызвана логирующая функция. Другими словами, первый пример работал как раз потому, что мы использовали макросы, которые были заменены генерируемым кодом, помещая file! и line! напрямую в исходный код, предоставляя нам необходимую информацию (имя файла и номер строки теперь в исполняемом файле) -8-. Rust включает в себя концепт атрибутов, который нужен для пометки кода. Например, функция тестирования выглядит так: Запуск cargo test запустит данную функцию. Атрибутивные макросы позволяют вам создавать новые атрибуты, который подобны "родным" атрибутам, но имеют другие эффекты. На текущий момент существует важное ограничение: в компиляторе из ветки stable работают только макросы использующие атрибут derive, в то время как пользовательские атрибуты работают в ночных сборках. Рассмотрим разницу ниже. Рассматривая преимущества, даваемые атрибутивными макросами, целесообразно сравнить код, который может манипулировать исходным кодом, с тем, который не может это делать. Атрибут derive используется в Rust для генерации реализации типажей. Давайте посмотрим на PartialEq. Здесь мы создаем структуру, экземпляры которой хотим проверять на равенство ( использовать ==), поэтому мы получаем реализацию PartialEq -9-. Мы могли бы реализовать PartialEq самостоятельно, но наша реализация была бы тривиальной, ибо мы хотим только проверять объекты на равенство: Данный код также генерирует нам компилятор, так что использование макроса экономит нам время, однако, что важнее, избавляет нас от необходимости поддержки проверяющего на равенство кода в актуальном состоянии. Если мы добавим поле в структуру, нам нужно изменить проверку в нашей ручной реализации PartialEq, иначе (например, если мы забудем изменить код проверки) проверка разных объектов может пройти успешно. Избавление от бремени поддержки является большим преимуществом, который предоставляет нам атрибутный макрос. Мы написали код структуры в одном месте и автоматически получили реализацию функции проверки и гарантии времени компиляции того, что код проверки соответствует текущему определению структуры. Ярким примером сказанного является пакет serde, используемый для сериализации данных, и без макросов нам необходимо было бы использовать строки для указания serde на названия полей структур, поддерживая эти строки в актуальном состоянии относительно определения структуры -10-. derive является одной из многих возможностей генерации кода атрибутивными макросами, а не только реализации типажей. На данный момент это доступно в ночных сборках, что, надеюсь, будет стабилизировано в текущем году. Наиболее выдающимся случаем использования на текущий момент является Rocket — библиотека для написания веб-серверов. Создание REST-endpoint'ов требует добавления атрибута к функции, так что теперь функция содержит всю необходимую информацию для обработки запроса. Если вы работали с веб-библиотеками в других языка (например, Flask или Spring), то данный стиль для вас, вероятно, не нов. Я не буду здесь сравнивать эти библиотеки, отмечу лишь, что вы можете писать подобный код и в Rust, пользуясь его преимуществами (высокая производительность получаемого нативного кода и т. д.) -11-. Макросы не идеальны, рассмотрим их некоторые недостатки: Макросы являются мощным инструментом, который может помочь в разработке. Надеюсь, смог внушить вам мысль, что макросы в Rust являются положительным явлением и имеют случаи, когда их применение уместно. -1-: Не путайте с возможностью const fn.
-2-: Известны как Макросы 1.1.
-3-: Замена макроса сгенерированным кодом называется расширением макроса.
-4-: Например, printf в C, String.Format в C#, форматирование строк в Python.
-5-: format! занимается форматированием строки, которая может использоваться макросами println! и другими.
-6-: varargs использует format!. Данная возможность (varargs) входит в противоречие с решением на запрет перегрузки функций, поэтому использование макроса очень уместно — не нужно добавлять поддержку в ядро языка.
-7-: Scala имеет хорошую реализацию интерполяции строк, которая делает проверки на стадии компиляции. Не знаю, будет ли добавлена интерполяция строк в Rust, хотя мы уже видели подобные примеры: try! развился из макроса во встроенную в язык возможность, так что подобное возможно при целесообразности.
-8-: У Rust есть проблема — паникующие методы (например, unwrap и expect) выдают бесполезные сообщения об ошибке, потому что не имеют доступа к информации о вызывающем коде.
-9-: PartialEq — типаж, используемый для проверки объектов на равенство, мы также используем Eq для корректности. Документация PartialEq объясняет, почему в Rust имеется подобное деление.
-10-: Проблема может быть решена рефлексией, которая не поддерживается в Rust, ибо противоречит дизайну языка, так как уменьшает производительность времени выполнения, ибо требует соответствующий runtime.
-11-: Sergio Benitez, автор Rocket, сделал связанное с этим хорошее выступление.