я кстати про авиационные дела слышал такой наброс, что все эти системы продажи/бронирования билетов работают поверх какой-то просто супер-архаичной ситемы

и с ним нужно работать, оно pop3/smtp

и всё плейн текстом, да?

поэтому на стойке регистрации у них какие-то факсоподобные хрени, да?

Есть итератор по сущностям, лежащим в KV, и фильтр, позволяющий их фильтровать. Проблема в том, что фильтр не stateless и требует хранилище в виде хэшмапы. То есть сейчас не получается сконструировать итератор с фильтром и вернуть его из функции из-за заимствования хэшмапы, которая на стеке функции. Передавать мутабельный референс на пустую хэшмапу в функцию не хочется, это как-то слишком сишно и вообще фу, я бы первый камнем в автора такого API кинул. Собстно вопрос: как можно передать хэшмапу в контекст итератора, чтобы она вместе с ним мувнулась из ф-и? Без написания своего итератора это возможно?

.filter() принимает что угодно, что имплементит FnMut(...)..., причём принимает во владение. Сделай тип, который хранит внутри себя нужную хэшмапу и имплементит FnMut

.filter() принимает что угодно, что имплементит FnMut(...)..., причём принимает во владение. Сделай тип, который хранит внутри себя нужную хэшмапу и имплементит FnMut

Меня еще такая мысль посетила: зачем нам вообще impl Trait как сущность в синтаксисе? Что мешало сделать просто Trait? Как бы в противовес трейтобъектам, которые в синтаксисе описываются как ссылки на трейт, здесь просто возвращать и принимать трейт, конкретный тип выводится компилятором. Типа fn generic(a: impl Iterator<Item=A>) -> impl Iterator<Item=B>; станет fn generic(a: Iterator<Item=A>) -> Iterator<Item=B> Может кто-то видел такой RFC?

для единобразия