Как-то я сказал своему коллеге, что в Rust имеются макросы, ему показалось, что это плохо. Раньше у меня была такая же реакция, но Rust показал мне, что макросы не обязательно плохи.

Где и как их уместно применять? Смотрите под катом.

Почему мы должны опасаться макросов

Макросы являются формой метапрограммирования: они являются кодом, который манипулирует кодом. Метапрограммирование получило плохую репутацию, потому что при их использовании нелегко уберечься от написания плохого кода. Примерами служат #define в C, который легко может взаимодействовать с кодом непредсказуемым образом, или eval в JavaScript, который увеличивают опасность инъекции кода.

О макросах в Rust

Многие их этих проблем могут быть решены при использовании необходимых средств, макросы же предоставляют некоторые такие средства:

• генерирование избыточного/тривиального кода (boilerplate) вместо его ручного написания.
• расширение языка перед тем, как будет добавлен новый синтаксис, закрытие пробелов в языке.
• оптимизация производительности — ибо некоторые действия, которые ранее выполнялись во время исполнения, теперь исполняются на стадии компиляции -1-.

Для того чтобы достичь этих целей, Rust включает в себя два вида макросов -2-. Они известны под разными названиями (процедурные, декларативные, macro_rules, и т. д.), хотя я считаю, что данные имена несколько запутывают. К счастью, они не так важны, поэтому я буду называть их функциональные и атрибутные.

Причиной того, что имеется два типа макросов является то, что они хорошо подходят для решения разных задач:

• функциональные: легко включить в код.
• атрибутные: лучше подходят для генерации кода, который не вписывается в окружающий код.

Во всем остальном результаты их применения схожи: компилятор "стирает" макросы во время компиляции, заменяя их кодом, генерирующимся из макроса, и компилируя его с "обычным", не макро-кодом -3-. Реализация двух типов макросов сильно отличается, но мы не будет здесь глубоко в это вдаваться.

Почему функциональные макросы

Функциональный макрос может быть исполнен почти как функция. Данный вид макросов имеет ! в вызове:

let x = action();       // вызов функции
let y = action!();      // вызов макроса

Зачем использовать макросы, когда можно использовать функции? Нужно помнить, что функциональные макросы ничего не имеют общего с функциями — они похожи на функции, чтобы их, макросы, было легче использовать. Поэтому вопрос стоит не в том, лучше данный тип макросов чем функции или нет, а в том, нужна ли нам возможность менять исходный код.

Полезные утверждения

Начнем с рассмотрения assert!, который используется для проверки того, что некоторое условие выполняется, вызывая панику (panic), если это не так. Они проверяются во время выполнения, так что же нам дает здесь метапрограммирование? Давайте посмотрим на сообщение, которое печатается, когда assert! завершается неудачно:

fn main() {
    let mut vec = Vec::new();   // создать пустой массив
    vec.push(1);                // добавить элемент в конец массива
    assert!(vec.is_empty())     // массив не пуст - assert! завершается неудачно
    // печатается:
    // thread 'main' panicked at 'assertion failed: vec.is_empty()', srcmain.rs:4
}

Данное сообщение содержит в себе условие, которое мы проверяем. Другими словами, макрос создает сообщение об ошибке, которое основано на исходном коде, мы же получаем содержательное сообщение об ошибке, не вставляя его в программу вручную.

Типо-безопасная работа с форматом строк

Во многих языках программирования поддерживается задание форматов вывода для строк -4-. Rust не является исключением и также поддерживает задание форматов строк посредством format!. Однако по-прежнему стоит вопрос: почему мы должны использовать метапрограммирование для решения проблемы? Давайте посмотрим на println! (он внутри использует format! для обработки переданной строки) -5-.

fn main() {
    // просто ввод
    println!("{} is {} in binary", 2, 10);
    // печатает: 2 is 10 in binary

    // вывод аргументов в числовой и двоичной форме
    println!("{0} is {0:b} in binary", 3)
    // печатает: 3 is 11 in binary
}

Есть много причин того, что format! реализован как макрос -6-, я же хочу подчеркнуть то, что он может разделить строку на части во время компиляции, проанализировать ее и проверить, является ли обработка переданных аргументов типо-безопасной. Мы можем изменить наш код и получить ошибку компиляции:

fn main() {
    println!("{} is {} in binary", 2/*, 10*/);
    // Ошибка компиляции: ожидались два аргумента, был передан один

    println!("{0} is {0:b} in binary", "3")
    // Ошибка компиляции: не реализовано представление строк в двоичном виде
}

Во многих других языках данные ошибки проявились бы во время выполнения, однако в Rust мы можем использовать макросы для того, чтобы выполнять данную проверку на этапе компиляции и генерировать производительный код для обработки формата строки без проверок времени выполнения -7-.

Легкое логирование

В этом примере немного вдадимся в экосистему языка. Rust имеет пакет log, который используется как главный фронтенд логирования. Как и другие решения для логирования, он предоставляет разные уровни логирования, но, в отличие от других решений, данные уровни представляются макросами, а не функциями.

Логирование показывает мощность метапрограммирования в том, как оно использует макросы file! и line!; Данные макросы дают возможность установить точное место расположения вызова функции логирования в исходном коде. Давайте посмотрим на пример. Так как log является фронтендом, добавим бэкенд, пакет flexi_logger.

#[macro_use] extern crate log;
extern crate flexi_logger;

use flexi_logger::{Logger, LogSpecification, LevelFilter};

fn main() {
    // Установим `trace` в качестве минимального уровня логирования
    let log_config = LogSpecification::default(LevelFilter::Trace).build();

    Logger::with(log_config)
        .format(flexi_logger::opt_format)   // Specify how we want the logs formatted
        .start()
        .unwrap();

    // Логирование готово к использованию. Используем его для отладки алгоритма
    info!("Fired up and ready!");

    complex_algorithm()
}

fn complex_algorithm() {
    debug!("Running complex algorithm.");
    for x in 0..3 {
        let y = x * 2;
        trace!("Step {} gives result {}", x, y)
    }
}

Эта программа напечатает:

[2018-01-25 14:48:42.416680 +01:00] INFO [srcmain.rs:16] Fired up and ready!
[2018-01-25 14:48:42.418680 +01:00] DEBUG [srcmain.rs:22] Running complex
algorithm.
[2018-01-25 14:48:42.418680 +01:00] TRACE [srcmain.rs:25] Step 0 gives
result 0
[2018-01-25 14:48:42.418680 +01:00] TRACE [srcmain.rs:25] Step 1 gives
result 2
[2018-01-25 14:48:42.418680 +01:00] TRACE [srcmain.rs:25] Step 2 gives
result 4

Как вы видите, наши логи содержат имена файлов и номера строк.

• мы получаем данную информацию без накладных расходов времени выполнения на получение этих данных.
• информация корректна и полезна.

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

Если мы заменим логирующие макросы на функции, то по-прежнему можем вызывать file! и line!:

fn info(input: String) {    // Надуманный вариант info!
    Log::log(
        logger(),
        RecordBuilder::new()
            .args(input)
            .file(Some(file!()))
            .line(Some(line!()))
            .build()
    )
}

А данный код вывел бы следующее:

[2018-01-25 14:48:42.416680 +01:00] INFO [srcloggersinfo.rs:7] Fired up and ready!

Имя файла и номер строки бесполезны, ибо указывают на то, где была вызвана логирующая функция. Другими словами, первый пример работал как раз потому, что мы использовали макросы, которые были заменены генерируемым кодом, помещая file! и line! напрямую в исходный код, предоставляя нам необходимую информацию (имя файла и номер строки теперь в исполняемом файле) -8-.

Почему атрибутные макросы

Rust включает в себя концепт атрибутов, который нужен для пометки кода. Например, функция тестирования выглядит так:

#[test]     // <- аттрибут
fn my_test() {
    assert!(1 > 0)
}

Запуск cargo test запустит данную функцию. Атрибутивные макросы позволяют вам создавать новые атрибуты, который подобны "родным" атрибутам, но имеют другие эффекты. На текущий момент существует важное ограничение: в компиляторе из ветки stable работают только макросы использующие атрибут derive, в то время как пользовательские атрибуты работают в ночных сборках. Рассмотрим разницу ниже.

Рассматривая преимущества, даваемые атрибутивными макросами, целесообразно сравнить код, который может манипулировать исходным кодом, с тем, который не может это делать.

Получение избыточного кода (boilerplate)

Атрибут derive используется в Rust для генерации реализации типажей. Давайте посмотрим на PartialEq.

#[derive(PartialEq, Eq)]
struct Data {
    content: u8
}

fn main() {
    let data = Data { content: 2 };
    assert!(data == Data { content: 2 })
}

Здесь мы создаем структуру, экземпляры кодой хотим проверять на равенство ( использовать ==), поэтому мы получаем реализацию PartialEq -9-. Мы могли бы реализовать PartialEq самостоятельно, но наша реализация была бы тривиальной, ибо мы хотим только проверять объекты на равенство:

impl PartialEq for Data {
    fn eq(&self, other: &Data) -> bool {
        self.content == other.content
    }
}

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

Избавление от бремени поддержки является большим преимуществом, который предоставляет нам атрибутный макрос. Мы написали код структуры в одном месте и автоматически получили реализацию функции проверки и гарантии времени компиляции того, что код проверки соответствует текущему определению структуры. Ярким примером сказанного является пакет serde, используемый для сериализации данных, и без макросов нам необходимо было бы использовать строки для указания serde на названия полей структур, поддерживая эти строки в актуальном состоянии относительно определения структуры -10-.

Derive с преимуществами

derive является одной из многих возможностей генерации кода атрибутивными макросами, а не только реализации типажей. На данный момент это доступно в ночных сборках, что, надеюсь, будет стабилизировано в текущем году.

Наиболее выдающимся случаем использования на текущий момент является Rocket — библиотека для написания веб-серверов. Создание REST-endpoint'ов требует добавления атрибута к функции, так что теперь функция содержит всю необходимую информацию для обработки запроса.

#[post("/user", data = "<new_user>")]
fn new_user(admin: AdminUser, new_user: Form<User>) -> T {
    //...
}

Если вы работали с веб-библиотеками в других языка (например, Flask или Spring), то данный стиль для вас, вероятно, не нов. Я не буду здесь сравнивать эти библиотеки, отмечу лишь, что вы можете писать подобный код и в Rust, пользуясь его преимуществами (высокая производительность получаемого нативного кода и т. д.) -11-.

Недостатки

Макросы не идеальны, рассмотрим их некоторые недостатки:

• увеличенное время компиляции, так как тратится время на получение кода из макроса и компиляцию данного кода.
• Макросы могут привести к увеличению размера машинного кода, ибо легко впасть в копипаст при их использовании, при котором маленькая строка может развернуться в большой блок кода. Раньше это было проблемой пакета clap, о котором автор написал хорошую заметку с описанием проблемы и то, как посадил код на диету.
• отладка становится сложнее, ибо нужно отлаживать сгенерированный код. К счастью, имеются инструменты, которые могут вам помочь. Читаемость и информативность сообщений об ошибке при использовании макросов зависит не от компилятора, а от авторов макроса. Опять же, имеются необходимые инструменты (например, compiler_error! и пакеты подобные syn).
• перегрузка DSL (немного субъективный пункт). Например, format! принимает строку, написанную на мини-языке, который является не Rust'ом, а DSL. Хотя DSL является мощным инструментом, его использование легко может ввести в затруднение, если разработчик задумает создать свой свой собственный встроенный язык. Если надумаете писать DSL, помните, что большие возможности подразумевают большую ответственность, и то, что вы можете сделать DSL, не подразумевает необходимости делать это.

Выводы

Макросы являются мощным инструментом, который может помочь в разработке. Надеюсь, смог внушить вам мысль, что макросы в 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, сделал связанное с этим хорошее выступление.

Автор: Булат Мусин

Источник