Итераторы и замыкания — бесплатный тест онлайн

Вопрос 1 из 25

Какая реализация выражает механизм «Ленивость» без лишнего копирования?

let mut calls = 0;
let iter = [1, 2, 3].iter().map(|n| { calls += 1; n * 2 });
println!("{calls}");
drop(iter);

Продублировать реализацию для каждого известного типа вокруг `calls`, вместо того чтобы исправить границы обобщения «Ленивость». Клонировать захваченное состояние перед каждым вызовом `calls`, не уточняя требуемый трейт вызова или время жизни. Добавить потребляющую операцию, если вычисление должно произойти; если нужны только побочные эффекты, явный for обычно читается честнее, чем map. Собирать каждый промежуточный итератор в Vec, чтобы ленивость не влияла на порядок. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Заменить текущую форму `calls` на `Box<dyn Trait>` во всех местах, не проверяя владение, объектобезопасность и стоимость вызова.

Вопрос 2 из 25

Какое объяснение механизма «Адаптеры» не смешивает компиляцию и выполнение?

Fn, FnMut и FnOnce выбираются программистом явной аннотацией, а не способом использования захватов. Blanket impl всегда имеет меньший приоритет, чем конкретная реализация, поэтому пересечения допустимы. Trait bounds проверяются при выполнении, когда конкретный метод впервые вызван. Адаптеры iterator обычно ленивы и создают новый итератор; потребляющий метод вроде collect, sum или for_each запускает обход. Iterator выполняет адаптеры при их создании, даже если результат никогда не потребляется.

Вопрос 3 из 25

Где заканчивается гарантия обычного сценария для «Владение в closure»?

move-замыкание может реализовать Fn, если лишь читает перемещённые данные; наоборот, замыкание без move станет FnOnce, если переместит значение при вызове. Добавление метода в публичный трейт не влияет на существующие реализации пользователей. Из этого следовало бы, что иной порядок операций для «Владение в closure» ничего не меняет. Ассоциированный тип и параметр типа взаимозаменяемы для всех контрактов вызывающего кода. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Тогда поведение «Владение в closure» при раннем выходе выводили бы из обычного пути. Переход с impl Trait на dyn Trait не меняет владение, layout и стоимость вызова. В результате «Владение в closure» считали бы безопасным и на путях, которых пример не выполняет. Один вызов замыкания подтверждает, что оно реализует Fn и может вызываться повторно. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Поэтому ошибочный сценарий вокруг «Владение в closure» не проверяли бы отдельно.

Вопрос 4 из 25

Что проверяет `Vec::new`, если не расширять вывод за пределы выполненного пути?

let mut seen = Vec::new();
let first = [1, 2, 3].iter().inspect(|n| seen.push(**n)).find(|n| **n == 2);
assert_eq!(first, Some(&2));
assert_eq!(seen, vec![1, 2]);

Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. find прекращает обход после совпадения, поэтому inspect не увидит третий элемент. Если основной путь стабилен, ранний выход и повторный вход можно не воспроизводить отдельно. Контракт `iter` считался бы одинаковым при любом состоянии входа. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Дополнительный сценарий вокруг `Vec::new` при таком толковании уже не требуется. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же.

Вопрос 5 из 25

Что нужно пересмотреть в использовании `iterator_is_lazy`, чтобы код стал корректным?

#[test]
fn iterator_is_lazy() {
    let calls = std::cell::Cell::new(0);
    let it = [1, 2].iter().map(|x| { calls.set(calls.get() + 1); x * 2 });
    assert_eq!(calls.get(), 0);
    assert_eq!(it.collect::<Vec<_>>(), vec![2, 4]);
    assert_eq!(calls.get(), 2);
}

Клонировать захваченное состояние перед каждым вызовом `iterator_is_lazy`, не уточняя требуемый трейт вызова или время жизни. Для итератора проверять пустой ввод, частичное потребление, порядок элементов и число вызовов; не ограничиваться итоговым collect на одном обычном наборе. Заменить текущую форму `iterator_is_lazy` на `Box<dyn Trait>` во всех местах, не проверяя владение, объектобезопасность и стоимость вызова. Продублировать реализацию для каждого известного типа вокруг `iterator_is_lazy`, вместо того чтобы исправить границы обобщения «Тестирование и инструменты Cargo». Собирать каждый промежуточный итератор в Vec, чтобы ленивость не влияла на порядок. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. В результате `iterator_is_lazy` считали бы безопасным и на путях, которых пример не выполняет.

Вопрос 6 из 25

Какая часть механизма «Итераторы Iterator» зафиксирована тестом `std::iter::FusedIterator`?

use std::iter::FusedIterator;
fn require_fused<I: FusedIterator>(_it: I) {}
require_fused([1, 2].into_iter());

Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Контракт `require_fused` считался бы одинаковым при любом состоянии входа. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Успешная ветвь служит достаточным доказательством поведения при ошибке и повторном выполнении. Проверку ошибки для `require_fused` при таком подходе заменили бы успешным примером. Граница FusedIterator явно фиксирует обещание, что после None элементы больше не появятся. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Дополнительный сценарий вокруг `std::iter::FusedIterator` при таком толковании уже не требуется.

Вопрос 7 из 25

Какой способ правки делает использование `String::from` корректным и явным?

let text = String::from("hello");
let consume = move || text;
let value = consume();
// let again = consume();

Если нужны повторные вызовы, возвращать clone осознанно либо захватывать ссылку и не перемещать значение из окружения. Добавить Clone ко всем trait bounds, даже если реализация использует только ссылки. Клонировать захваченное состояние перед каждым вызовом `text`, не уточняя требуемый трейт вызова или время жизни. Заменить текущую форму `text` на `Box<dyn Trait>` во всех местах, не проверяя владение, объектобезопасность и стоимость вызова. Продублировать реализацию для каждого известного типа вокруг `text`, вместо того чтобы исправить границы обобщения «Владение в closure».

Вопрос 8 из 25

На какую часть контракта распространяется проверка `iterator_is_lazy`?

#[test]
fn iterator_is_lazy() {
    let calls = std::cell::Cell::new(0);
    let it = [1, 2].iter().map(|x| { calls.set(calls.get() + 1); x * 2 });
    assert_eq!(calls.get(), 0);
    assert_eq!(it.collect::<Vec<_>>(), vec![2, 4]);
    assert_eq!(calls.get(), 2);
}

Код компилируется, но ленивый итератор запускает фоновую задачу до терминальной операции. Такая запись допустима, так как адаптер итератора выполняет работу сразу при создании цепочки. Фрагмент успешно соберётся: dyn Trait сохраняет конкретный размер значения внутри типа указателя без косвенности. Тест проверяет два момента контракта: до потребления вызовов нет, после collect обработан каждый элемент. Сборка пройдёт, поскольку blanket impl автоматически разрешает любые пересечения реализаций. Такое рассуждение переносило бы вывод о `iterator_is_lazy` на неисполненную ветвь.

Вопрос 9 из 25

Какой край контракта «Адаптеры» чаще всего остаётся незамеченным?

Добавление метода в публичный трейт не влияет на существующие реализации пользователей. Поэтому ошибочный сценарий вокруг «Адаптеры» не проверяли бы отдельно. Порядок filter и map может менять стоимость и даже семантику, если преобразование дорогое, падающее или имеет побочные эффекты. Ассоциированный тип и параметр типа взаимозаменяемы для всех контрактов вызывающего кода. Ленивую цепочку можно не потреблять в тесте: сам факт её создания подтверждает побочные эффекты. Переход с impl Trait на dyn Trait не меняет владение, layout и стоимость вызова. Контракт «Адаптеры» считался бы одинаковым при любом состоянии входа.

Вопрос 10 из 25

Какая часть механизма «Адаптеры» зафиксирована тестом `copied`?

let out: Vec<_> = [1, 2, 3].iter().copied().map(|n| n + 1).collect();
assert_eq!(out, vec![2, 3, 4]);

Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. copied переводит Iterator<Item=&i32> в Iterator<Item=i32>, после чего map работает со значениями без двойного разыменования. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Дополнительный сценарий вокруг `copied` при таком толковании уже не требуется. Раз тест прошёл, производительность решения тоже можно считать подтверждённой. Дополнительный сценарий вокруг `copied` при таком толковании уже не требуется. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Дополнительный сценарий вокруг `copied` при таком толковании уже не требуется.

Вопрос 11 из 25

Чем завершится выполнение фрагмента с `into_iter`?

let mut it = vec![10, 20].into_iter();
println!("{:?} {:?} {:?}", it.next(), it.next(), it.next());

Проверка типов завершится ошибкой: итератор потребляется терминальной операцией. Код компилируется, но ленивый итератор запускает фоновую задачу до терминальной операции. Код пройдёт проверку компилятора: адаптер итератора выполняет работу сразу при создании цепочки. Код печатает Some(10) Some(20) None: next изменяет состояние итератора и после исчерпания возвращает None. Ошибка возникнет на этапе компиляции: метод по умолчанию использует обязательный метод трейта.

Вопрос 12 из 25

Какое ограничение языка определяет поведение «Ленивость»?

Move определяет только потокобезопасность замыкания и не влияет на способ захвата. Адаптер итератора выполняет работу сразу при создании цепочки. Проверку ошибки для «Ленивость» при таком подходе заменили бы успешным примером. Iterator выполняет адаптеры при их создании, даже если результат никогда не потребляется. Из этого следовало бы, что иной порядок операций для «Ленивость» ничего не меняет. Замыкание с move всегда реализует Fn и может вызываться неограниченно. Следовательно, поведение `map` считалось бы одинаковым для всех допустимых типов. Итераторные адаптеры ленивы: элементы и замыкания вычисляются по запросу потребителя, часто по одному значению.

Вопрос 13 из 25

Как изменятся значения к моменту завершения фрагмента?

let mut calls = 0;
let iter = [1, 2, 3].iter().map(|n| { calls += 1; n * 2 });
println!("{calls}");
drop(iter);

Компилятор примет фрагмент: адаптер итератора выполняет работу сразу при создании цепочки. Код компилируется, но замыкание автоматически клонирует захваченное состояние между вызовами. Код печатает 0: создание map-адаптера не запускает замыкание, а итератор уничтожается без потребления. Код компилируется, но ленивый итератор запускает фоновую задачу до терминальной операции. Тогда поведение `iter` при раннем выходе выводили бы из обычного пути. Ошибка возникнет на этапе компиляции: замыкание захватывает значение по ссылке.

Вопрос 14 из 25

Что устанавливает сценарий `String::from` и где проходит граница его вывода?

let text = String::from("hi");
let len = move || text.len();
assert_eq!(len(), 2);
assert_eq!(len(), 2);

Контракт считается покрытым после обычного запуска; различия при отмене и частичном результате несущественны. Следовательно, для `len` не понадобилось бы явное предусловие. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Проверку ошибки для `len` при таком подходе заменили бы успешным примером. Хотя text захвачен по значению, замыкание только читает его и поэтому может вызываться многократно как Fn. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Дополнительный сценарий вокруг `String::from` при таком толковании уже не требуется. По этой логике отдельная проверка `len` на другом входе считалась бы лишней. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной.

Вопрос 15 из 25

Какая правка выдержит ревью контракта «Адаптеры»?

let values = [1, 2, 3, 4];
let sum: i32 = values.iter().filter(|n| **n % 2 == 0).map(|n| n * 10).sum();
println!("{sum}");

Строить цепочку из адаптеров с ясными этапами; при сложных ссылочных уровнях использовать copied или destructuring, чтобы не скрывать типы звёздочками. Заменить текущую форму `values` на `Box<dyn Trait>` во всех местах, не проверяя владение, объектобезопасность и стоимость вызова. Продублировать реализацию для каждого известного типа вокруг `values`, вместо того чтобы исправить границы обобщения «Адаптеры». Добавить Clone ко всем trait bounds, даже если реализация использует только ссылки. При каждом таком вызове появляется отдельный владелец и оплачивается копирование данных. В результате `iter` считали бы безопасным и на путях, которых пример не выполняет. Клонировать захваченное состояние перед каждым вызовом `values`, не уточняя требуемый трейт вызова или время жизни.

Вопрос 16 из 25

Что нужно проверить отдельно при переносе механизма «Ленивость» в библиотечный код?

Ассоциированный тип и параметр типа взаимозаменяемы для всех контрактов вызывающего кода. Тогда различия между обычным и граничным случаем для «Ленивость» исчезли бы. Добавление метода в публичный трейт не влияет на существующие реализации пользователей. Один вызов замыкания подтверждает, что оно реализует Fn и может вызываться повторно. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Побочные эффекты внутри ленивой цепочки могут не выполниться полностью при take, find, short-circuit или раннем прекращении обхода. Ленивую цепочку можно не потреблять в тесте: сам факт её создания подтверждает побочные эффекты. Следовательно, для «Ленивость» не понадобилось бы явное предусловие.

Вопрос 17 из 25

Как проявится механизм «Владение в closure» при выполнении кода?

let text = String::from("hello");
let consume = move || text;
let value = consume();
// let again = consume();

До выполнения код дойдёт без ошибки компиляции, поскольку замыкание с move всегда реализует Fn и может вызываться неограниченно. Rust примет этот код, поскольку dyn Trait сохраняет конкретный размер значения внутри типа указателя без косвенности. Из этого следовало бы, что иной порядок операций для `String::from` ничего не меняет. Замыкание перемещает String в окружение, а затем возвращает его при первом вызове; оно реализует только FnOnce. Замыкание копирует String в окружение, а затем возвращает его при первом вызове; оно реализует только FnOnce. Компилятор примет фрагмент: trait bound проверяется только при фактическом вызове метода во время выполнения. Проверку ошибки для `String::from` при таком подходе заменили бы успешным примером.

Вопрос 18 из 25

Что произойдёт с ресурсом после завершения показанной области?

let values = [1, 2, 3, 4];
let sum: i32 = values.iter().filter(|n| **n % 2 == 0).map(|n| n * 10).sum();
println!("{sum}");

Rust примет этот код, поскольку blanket impl автоматически разрешает любые пересечения реализаций. Код печатает 60: filter пропускает ссылки на 2 и 4, map вычисляет 20 и 40, а sum потребляет цепочку. Компиляция закончится диагностикой: метод по умолчанию использует обязательный метод трейта. Код компилируется, но ленивый итератор запускает фоновую задачу до терминальной операции. Из этого следовало бы, что иной порядок операций для `iter` ничего не меняет. Этот фрагмент будет отклонён: итератор потребляется терминальной операцией.

Вопрос 19 из 25

Какой вывод допустим после запуска `iterator_is_lazy` и чего он не доказывает?

#[test]
fn iterator_is_lazy() {
    let calls = std::cell::Cell::new(0);
    let it = [1, 2].iter().map(|x| { calls.set(calls.get() + 1); x * 2 });
    assert_eq!(calls.get(), 0);
    assert_eq!(it.collect::<Vec<_>>(), vec![2, 4]);
    assert_eq!(calls.get(), 2);
}

# cargo test iterator_is_lazy -- --exact

Фильтр с --exact запускает ровно именованный тест и удобен при отладке поведения конкретной цепочки. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Тогда различия между обычным и граничным случаем для `iterator_is_lazy` исчезли бы. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. После успешного запуска основной ветви отдельные проверки ошибки, отмены и повторного вызова становятся избыточными. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки.

Вопрос 20 из 25

На какое правило следует опираться при ревью кода по теме «Итераторы Iterator»?

Iterator определяет связанный тип Item и метод next(&mut self) -> Option<Item>; многие адаптеры строятся поверх этого минимального протокола. Iterator выполняет адаптеры при их создании, даже если результат никогда не потребляется. Следовательно, поведение `into_iter` считалось бы одинаковым для всех допустимых типов. Адаптер итератора выполняет работу сразу при создании цепочки. Проверку ошибки для «Итераторы Iterator» при таком подходе заменили бы успешным примером. Любой трейт можно использовать как dyn Trait без ограничений на методы и Self. Проверку ошибки для «Итераторы Iterator» при таком подходе заменили бы успешным примером. Trait bounds проверяются при выполнении, когда конкретный метод впервые вызван. Тогда поведение «Итераторы Iterator» при раннем выходе выводили бы из обычного пути.

Вопрос 21 из 25

Какой вывод о механизме «Тестирование и инструменты Cargo» соответствует модели Rust?

Адаптер итератора выполняет работу сразу при создании цепочки. Поэтому ошибочный сценарий вокруг «Тестирование и инструменты Cargo» не проверяли бы отдельно. Iterator выполняет адаптеры при их создании, даже если результат никогда не потребляется. Unit-тест может наблюдать ленивость через счётчик вызовов, а property-подобные проверки полезны для законов размера, порядка и эквивалентности циклу. Dyn Trait сохраняет конкретный размер значения внутри типа указателя без косвенности. Blanket impl всегда имеет меньший приоритет, чем конкретная реализация, поэтому пересечения допустимы. Из этого следовало бы, что иной порядок операций для «Тестирование и инструменты Cargo» ничего не меняет.

Вопрос 22 из 25

Какое изменение окружения может повлиять на вывод о «Тестирование и инструменты Cargo»?

Ассоциированный тип и параметр типа взаимозаменяемы для всех контрактов вызывающего кода. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. По этой логике отдельная проверка «Тестирование и инструменты Cargo» на другом входе считалась бы лишней. Добавление метода в публичный трейт не влияет на существующие реализации пользователей. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Ленивую цепочку можно не потреблять в тесте: сам факт её создания подтверждает побочные эффекты. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Если generic-код компилируется для одного типа, скрытые ограничения для других типов невозможны. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. В результате «Тестирование и инструменты Cargo» считали бы безопасным и на путях, которых пример не выполняет. Exact size_hint является оценкой с нижней и необязательной верхней границей; тест не должен требовать точного значения от произвольного Iterator.

Вопрос 23 из 25

Какой случай чаще всего обнаруживает скрытую ошибку в реализации «Итераторы Iterator»?

Если generic-код компилируется для одного типа, скрытые ограничения для других типов невозможны. Поэтому ошибочный сценарий вокруг «Итераторы Iterator» не проверяли бы отдельно. Добавление метода в публичный трейт не влияет на существующие реализации пользователей. По этой логике отдельная проверка «Итераторы Iterator» на другом входе считалась бы лишней. После первого None большинство стандартных итераторов остаются исчерпанными, но общий трейт не обещает fused-поведение без FusedIterator. Ленивую цепочку можно не потреблять в тесте: сам факт её создания подтверждает побочные эффекты. Тогда различия между обычным и граничным случаем для «Итераторы Iterator» исчезли бы. Ассоциированный тип и параметр типа взаимозаменяемы для всех контрактов вызывающего кода. По этой логике отдельная проверка «Итераторы Iterator» на другом входе считалась бы лишней.

Вопрос 24 из 25

Что важно понимать о механизме «Владение в closure», прежде чем менять код?

Move определяет только потокобезопасность замыкания и не влияет на способ захвата. Следовательно, поведение `String::from` считалось бы одинаковым для всех допустимых типов. Fn, FnMut и FnOnce выбираются программистом явной аннотацией, а не способом использования захватов. Следовательно, для «Владение в closure» не понадобилось бы явное предусловие. Набор Fn, FnMut и FnOnce определяется тем, что замыкание делает с захваченными значениями; ключевое слово move задаёт способ захвата, но не само по себе call trait. Trait bound проверяется только при фактическом вызове метода во время выполнения. Замыкание с move всегда реализует Fn и может вызываться неограниченно. Контракт «Владение в closure» считался бы одинаковым при любом состоянии входа.

Вопрос 25 из 25

Как устранить исходную ошибку, связанную с `into_iter`?

let mut it = vec![10, 20].into_iter();
println!("{:?} {:?} {:?}", it.next(), it.next(), it.next());

Сделать трейт объектобезопасным удалением всех методов, которые возвращают Self, без альтернативного API. Принимать Iterator или IntoIterator по нужному контракту; не сохранять ссылку на временный итератор, который сразу уничтожается. Клонировать захваченное состояние перед каждым вызовом `vec`, не уточняя требуемый трейт вызова или время жизни. Продублировать реализацию для каждого известного типа вокруг `vec`, вместо того чтобы исправить границы обобщения «Итераторы Iterator». Собирать каждый промежуточный итератор в Vec, чтобы ленивость не влияла на порядок. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Из этого следовало бы, что иной порядок операций для `into_iter` ничего не меняет.