Не очень понятно что вы имеете ввиду под «не залезают». В rust borrow checker проверит все lifetime и их сходимость в теле функции.
Есть правило lifetime elision, по которому если пропущен явный lifetime у аргумента и возвращаемого значения, то подразумевается, что он один и равен аргументу. Вы просто отвязали аргумент-ссылку от возвращаемой структуры, как того и требует сигнатура.
А for у вас по чем, коллекция интерфейсов? Ну в расте будет коллекция Box<dyn SomeTrait>, где у SomeTrait есть функция опроса конкретного API, возвращающая Result<T, Err>. Err может быть общий для всех API или уникальный для каждого конкретного.
Почти любой код на исключениях переписывается на Result в более явном виде. А для типов-сумм для объединения исключений уже давно придуманы всякие thiserror и anyhow.
Ну и что тут многие не могут освободиться от try/catch в пользу монадической обработки ошибок или банального Result<T, E>, так это печаль конечно. Ибо это эквивалентные модели control flow при наличии поддержки языком программирования соответствующих операторов.
Не очень понятно что вы имеете ввиду под «не залезают». В rust borrow checker проверит все lifetime и их сходимость в теле функции.
Есть правило lifetime elision, по которому если пропущен явный lifetime у аргумента и возвращаемого значения, то подразумевается, что он один и равен аргументу. Вы просто отвязали аргумент-ссылку от возвращаемой структуры, как того и требует сигнатура.
Мне одному кажется, что примеры на rust компилируются только потому, что реальный аргумент-ссылка не используется в возвращаемом значении?
А for у вас по чем, коллекция интерфейсов? Ну в расте будет коллекция Box<dyn SomeTrait>, где у SomeTrait есть функция опроса конкретного API, возвращающая Result<T, Err>. Err может быть общий для всех API или уникальный для каждого конкретного.
Почти любой код на исключениях переписывается на Result в более явном виде. А для типов-сумм для объединения исключений уже давно придуманы всякие thiserror и anyhow.
Ну и что тут многие не могут освободиться от try/catch в пользу монадической обработки ошибок или банального Result<T, E>, так это печаль конечно. Ибо это эквивалентные модели control flow при наличии поддержки языком программирования соответствующих операторов.
Очень интересен опыт сборки и общие впечатления от Norns.
В книге тоже такие вставки в листинг как (1), (2)? Может оформлять комментарии лучше как //комментарии ?