Условия, циклы и выражения — бесплатный тест онлайн

Вопрос 1 из 20

Как правильно истолковать результат проверки механизма «Цикл loop»?

let answer: i32 = loop { break 7; };
assert_eq!(answer, 7);

Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Проверка подтверждает, что значение после break становится результатом всего loop-выражения. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы. Раз тест прошёл, производительность решения тоже можно считать подтверждённой.

Вопрос 2 из 20

Какую гарантию даёт `String::from`, а какую нужно проверять отдельно?

let words = vec![String::from("a"), String::from("b")];
for w in &words { print!("{w}"); }
assert_eq!(words.len(), 2);

Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Одного успешного примера достаточно, чтобы считать проверенными и невыполненные ветви контракта. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Дополнительный сценарий вокруг `String::from` при таком толковании уже не требуется. Тогда различия между обычным и граничным случаем для `len` исчезли бы. Обход по &words не перемещает строки и сохраняет вектор доступным после цикла.

Вопрос 3 из 20

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

Блоки обеих ветвей могут возвращать разные типы, если в текущем запуске выбирается только одна ветвь. Бесконечный loop имеет никогда не возвращающий тип!, но наличие достижимого break меняет анализ и требует согласовать возвращаемое значение. Достаточно проверить один числовой вход: переполнение и преобразования не зависят от границ типа. После исчерпывающего match добавление нового варианта enum не требует пересмотра существующего кода. Unicode не влияет на срезы строк, когда индекс визуально указывает на первый символ. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение.

Вопрос 4 из 20

К какому результату приводит последовательность вокруг `loop`?

let value = 'outer: loop {
    loop {
        break 'outer 9;
    }
};
println!("{value}");

Код печатает 9: помеченный break завершает внешний loop и задаёт его значение. Этот фрагмент будет отклонён: две ветви if используют разные имена локальных переменных. До выполнения код дойдёт без ошибки компиляции, поскольку pattern matching автоматически добавляет ветвь для всех пропущенных вариантов. Проверка типов пропустит этот путь: rust неявно приводит обе ветви выражения к общему динамическому типу. Rust примет этот код, поскольку выход за границы массива возвращает None независимо от используемой операции.

Вопрос 5 из 20

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

let mut n = 0;
let result = loop {
    n += 1;
    if n == 3 { break n * 2; }
};
println!("{result}");

Оставить неохваченный вариант match и завершать программу через unreachable_unchecked(). Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Добавить `mut` или явное приведение типа рядом с `break`, сохранив прежнюю логику выражения и порядок вычислений. Использовать break value, если loop вычисляет результат; для простого повторения без результата оставить break без значения и тип (). Заменить выражение с `break` отдельным оператором и отбросить его значение, не меняя окружающий контракт «Цикл loop». Перенести проверку результата `break` на время выполнения и возвращать значение по умолчанию при несовпадении типов или ветвей.

Вопрос 6 из 20

Как изменится состояние программы в показанном сценарии «while и for»?

let mut sum = 0;
for n in 1..=4 { sum += n; }
while sum > 8 { sum -= 3; }
println!("{sum}");

for сначала даёт сумму 10, затем while один раз уменьшает её до 7; программа печатает 7. Компилятор отвергнет фрагмент, поскольку диапазон с включённой правой границей запрещён в цикле for. Такая запись допустима, так как rust неявно приводит обе ветви выражения к общему динамическому типу. Код компилируется, но переполнение целого всегда даёт одно и то же значение во всех профилях сборки. Rust примет этот код, поскольку выход за границы массива возвращает None независимо от используемой операции.

Вопрос 7 из 20

Какая правка выдержит ревью контракта «break со значением»?

let value = 'outer: loop {
    loop {
        break 'outer 9;
    }
};
println!("{value}");

Добавить `mut` или явное приведение типа рядом с `outer`, сохранив прежнюю логику выражения и порядок вычислений. Заменить выражение с `outer` отдельным оператором и отбросить его значение, не меняя окружающий контракт «break со значением». Для доступа к массиву использовать get_unchecked без предварительной проверки длины. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Поставить метку на тот loop, результат которого нужен, и использовать break label value; не пытаться вернуть значение из while или for. Перенести проверку результата `outer` на время выполнения и возвращать значение по умолчанию при несовпадении типов или ветвей.

Вопрос 8 из 20

Как сформулировать контракт механизма «while и for» без привязки к именам переменных?

Shadowing изменяет значение прежней привязки и поэтому требует mut. В результате «while и for» считали бы безопасным и на путях, которых пример не выполняет. Диапазон a..b не включает b, а a..=b включает; for потребляет объект IntoIterator и не требует ручного индекса. Выход за границы массива возвращает None независимо от используемой операции. Следовательно, для «while и for» не понадобилось бы явное предусловие. Точка с запятой не влияет на тип выражения блока. Следовательно, поведение `for` считалось бы одинаковым для всех допустимых типов. Rust неявно приводит обе ветви выражения к общему динамическому типу. Следовательно, поведение `for` считалось бы одинаковым для всех допустимых типов.

Вопрос 9 из 20

Какое правило Rust точнее всего описывает механизм «if-выражение»?

В Rust if возвращает значение, поэтому ветви, которые могут быть выбраны, должны иметь совместимый тип. Rust неявно приводит обе ветви выражения к общему динамическому типу. Точка с запятой не влияет на тип выражения блока. Следовательно, поведение `if` считалось бы одинаковым для всех допустимых типов. Оператор as всегда проверяет переполнение и возвращает Result при потере данных. If в Rust является только оператором управления и не может возвращать значение.

Вопрос 10 из 20

Какое решение делает ошибочный путь явным для вызывающего кода?

let mut sum = 0;
for n in 1..=4 { sum += n; }
while sum > 8 { sum -= 3; }
println!("{sum}");

Заменить выражение с `sum` отдельным оператором и отбросить его значение, не меняя окружающий контракт «while и for». Скрыть различие типов за строковым форматированием и затем разобрать значение обратно. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Добавить `mut` или явное приведение типа рядом с `sum`, сохранив прежнюю логику выражения и порядок вычислений. Для обхода коллекции предпочесть for по итератору; while уместен, когда условие меняется независимо от последовательного итератора. Перенести проверку результата `sum` на время выполнения и возвращать значение по умолчанию при несовпадении типов или ветвей.

Вопрос 11 из 20

Что должно войти в отрицательный тест механизма «if-выражение»?

Блоки обеих ветвей могут возвращать разные типы, если в текущем запуске выбирается только одна ветвь. Контракт «if-выражение» считался бы одинаковым при любом состоянии входа. Индекс, равный длине массива, относится к последнему элементу и не является отдельным случаем. Unicode не влияет на срезы строк, когда индекс визуально указывает на первый символ. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Проверку ошибки для «if-выражение» при таком подходе заменили бы успешным примером. Ветка без else допустима как выражение только там, где ожидается (), поскольку отсутствие ветки соответствует единичному значению. Достаточно проверить один числовой вход: переполнение и преобразования не зависят от границ типа.

Вопрос 12 из 20

Какой эксплуатационный край отличает контракт «while и for» от удачного примера?

Достаточно проверить один числовой вход: переполнение и преобразования не зависят от границ типа. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Unicode не влияет на срезы строк, когда индекс визуально указывает на первый символ. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Следовательно, для «while и for» не понадобилось бы явное предусловие. Итерация for по Vec по значению перемещает элементы, а по &Vec или &mut Vec заимствует их; выбор формы влияет на доступность коллекции после цикла. Различие debug и release не влияет на обычные арифметические операторы. После исчерпывающего match добавление нового варианта enum не требует пересмотра существующего кода. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются.

Вопрос 13 из 20

Какой сценарий нельзя выводить из одного положительного примера «break со значением»?

break с меткой из вложенного цикла может пропустить код после внутреннего loop, поэтому освобождение локальных ресурсов и ожидаемые побочные эффекты нужно проверять по реальному пути выхода. Достаточно проверить один числовой вход: переполнение и преобразования не зависят от границ типа. Тогда различия между обычным и граничным случаем для «break со значением» исчезли бы. Unicode не влияет на срезы строк, когда индекс визуально указывает на первый символ. Контракт «break со значением» считался бы одинаковым при любом состоянии входа. Блоки обеих ветвей могут возвращать разные типы, если в текущем запуске выбирается только одна ветвь. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Индекс, равный длине массива, относится к последнему элементу и не является отдельным случаем. В результате «break со значением» считали бы безопасным и на путях, которых пример не выполняет.

Вопрос 14 из 20

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

Точка с запятой не влияет на тип выражения блока. Следовательно, для «Цикл loop» не понадобилось бы явное предусловие. loop может быть выражением с результатом, который задаётся break; все достижимые break с значением должны быть совместимы по типу. Shadowing изменяет значение прежней привязки и поэтому требует mut. По этой логике отдельная проверка «Цикл loop» на другом входе считалась бы лишней. Rust неявно приводит обе ветви выражения к общему динамическому типу. Тогда различия между обычным и граничным случаем для «Цикл loop» исчезли бы. Оператор as всегда проверяет переполнение и возвращает Result при потере данных. Контракт «Цикл loop» считался бы одинаковым при любом состоянии входа.

Вопрос 15 из 20

Какой результат следует из типов и порядка действий в этом коде?

let enabled = true;
let value = if enabled { 10 } else { 20 };
println!("{value}");

Rust примет этот код, поскольку pattern matching автоматически добавляет ветвь для всех пропущенных вариантов. Проверка типов завершится ошибкой: все числовые литералы обязаны иметь явную аннотацию типа. Код компилируется и печатает 10: if является выражением, а обе ветви возвращают i32. Компиляция завершится успешно: выход за границы массива возвращает None независимо от используемой операции. До выполнения код дойдёт без ошибки компиляции, поскольку rust неявно приводит обе ветви выражения к общему динамическому типу.

Вопрос 16 из 20

Как правильно истолковать результат проверки механизма «if-выражение»?

let n = 3;
let label = if n > 0 { "positive" } else { "non-positive" };
assert_eq!(label, "positive");

Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы. Нормальный результат на одном входе позволяет распространить тот же вывод на отмену и частичное выполнение. Из этого следовало бы, что иной порядок операций для `assert_eq!` ничего не меняет. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Дополнительный сценарий вокруг `if` при таком толковании уже не требуется. Тест проверяет именно значение if-выражения, а не побочный эффект внутри ветвей. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки.

Вопрос 17 из 20

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

let enabled = true;
let value = if enabled { 10 } else { 20 };
println!("{value}");

Добавить `mut` или явное приведение типа рядом с `enabled`, сохранив прежнюю логику выражения и порядок вычислений. Добавить as-приведение в каждой ветви, даже если оно может молча потерять данные. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Перенести проверку результата `enabled` на время выполнения и возвращать значение по умолчанию при несовпадении типов или ветвей. Заменить выражение с `enabled` отдельным оператором и отбросить его значение, не меняя окружающий контракт «if-выражение». Сделать все ветви совместимыми по типу или вынести неодинаковые действия из выражения; точка с запятой не должна случайно превращать одну ветвь в ().

Вопрос 18 из 20

Какой результат даст этот фрагмент с `loop`?

let mut n = 0;
let result = loop {
    n += 1;
    if n == 3 { break n * 2; }
};
println!("{result}");

Компиляция закончится диагностикой: все числовые литералы обязаны иметь явную аннотацию типа. До выполнения код дойдёт без ошибки компиляции, поскольку shadowing изменяет тип уже существующей переменной без создания новой привязки. Код печатает 6: break завершает loop и передаёт значение всему выражению цикла. Такая запись допустима, так как pattern matching автоматически добавляет ветвь для всех пропущенных вариантов. Фрагмент успешно соберётся: rust неявно приводит обе ветви выражения к общему динамическому типу.

Вопрос 19 из 20

Какую регрессию должен ловить `loop`?

let found = 'search: loop {
    for n in 0..10 {
        if n == 4 { break 'search Some(n); }
    }
    break None;
};
assert_eq!(found, Some(4));

Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Тогда различия между обычным и граничным случаем для `assert_eq!` исчезли бы. Сценарий проверяет, что помеченный break возвращает Some(4) из внешнего loop, а не только завершает for. Отсутствие ошибки компиляции уже доказывает нужное свойство, поэтому поведение можно не проверять. По этой логике отдельная проверка `assert_eq!` на другом входе считалась бы лишней. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Если обычный путь проходит, поведение при отмене и повторном входе можно считать следствием того же теста. В результате `assert_eq!` считали бы безопасным и на путях, которых пример не выполняет.

Вопрос 20 из 20

Как лучше всего описать гарантию механизма «break со значением»?

Метод с &self получает независимую копию объекта и может свободно менять его поля. Значение через break разрешено для loop; метка определяет, какой именно цикл завершается и получает результат. Match разрешено оставлять неисчерпывающим, если недостающие варианты редки. Тогда различия между обычным и граничным случаем для «break со значением» исчезли бы. Выход за границы массива возвращает None независимо от используемой операции. Оператор as всегда проверяет переполнение и возвращает Result при потере данных. Поэтому ошибочный сценарий вокруг «break со значением» не проверяли бы отдельно.