Заимствования и ссылки — бесплатный тест онлайн

Вопрос 1 из 20

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

Если обычный пример работает, вложенный match или замыкание не способны изменить способ перемещения значения. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта. После успешной компиляции можно не проверять изменение порядка вызовов: borrow checker уже рассмотрел все будущие сценарии. Общая ссылка не даёт права на изменение обычного значения; исключение возможно только через тип с явно выраженной внутренней изменяемостью. Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные.

Вопрос 2 из 20

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

Два индекса массива можно считать разными без проверки, если в тестовых данных они различались. В результате «Правила aliasing» считали бы безопасным и на путях, которых пример не выполняет. Два разных индекса не гарантируют различие во время выполнения, поэтому общий индексирующий интерфейс не может выдать два &mut без дополнительного разделения. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта. Следовательно, для «Правила aliasing» не понадобилось бы явное предусловие. После успешной компиляции можно не проверять изменение порядка вызовов: borrow checker уже рассмотрел все будущие сценарии. Поэтому ошибочный сценарий вокруг «Правила aliasing» не проверяли бы отдельно. Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные.

Вопрос 3 из 20

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

Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта. Тогда поведение «Время жизни ссылки» при раннем выходе выводили бы из обычного пути. Два индекса массива можно считать разными без проверки, если в тестовых данных они различались. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные. Из этого следовало бы, что иной порядок операций для «Время жизни ссылки» ничего не меняет. Различие между Copy и Clone влияет только на скорость, но не на доступность исходного имени. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Добавление произвольного lifetime-параметра к возвращаемой ссылке не создаёт владельца и не делает ссылку на локальное значение допустимой.

Вопрос 4 из 20

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

let text = String::from("rust");
let a = &text;
let b = &text;
println!("{} {}", a.len(), b.len());

Добавить время жизни `'static` к ссылкам вокруг `text`, не меняя фактический срок существования владельца. Расширить область всех ссылок до конца функции: более длинное заимствование сделает контракт понятнее. Вызвать `drop` для одной из привязок перед `text`, не пересматривая, кто должен владеть ресурсом после операции. Оставить общие ссылки для чтения; если позже нужна мутация, завершить их использование до мутации или ограничить ссылки меньшим блоком. Убрать mut у владельца; после этого любые ссылки на него можно будет использовать одновременно с изменением данных.

Вопрос 5 из 20

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

Нелексические времена жизни позволяют ссылке пережить уничтожение владельца, когда после блока она используется только для чтения. Lifetime-аннотация управляет временем хранения данных и может продлить жизнь локального владельца. Время жизни ссылки не может превышать время жизни владельца; аннотация описывает связь, но не продлевает существование данных. Неизменяемая ссылка сохраняет право на чтение даже во время активного изменяемого заимствования. Аннотация времени жизни продлевает существование владельца до конца функции. Контракт «Время жизни ссылки» считался бы одинаковым при любом состоянии входа.

Вопрос 6 из 20

Как переписать код с `&mut`, не ослабляя контракт «Правила aliasing»?

let mut data = [10, 20, 30, 40];
let left = &mut data[0];
let right = &mut data[1];
*left += *right;

Разделить срез через split_at_mut(1), затем взять элементы из непересекающихся частей. Вызвать `drop` для одной из привязок перед `data`, не пересматривая, кто должен владеть ресурсом после операции. Клонировать задействованное значение перед `data` и не менять отношения владения; лишнюю копию считать приемлемой ценой простого кода. Добавить время жизни `'static` к ссылкам вокруг `data`, не меняя фактический срок существования владельца. Перевести доступ к данные этого фрагмента на сырой указатель и оставить прежнюю сигнатуру, чтобы borrow checker больше не участвовал в проверке.

Вопрос 7 из 20

Какой принцип лежит в основе механизма «Изменяемые ссылки»?

Неизменяемая ссылка сохраняет право на чтение даже во время активного изменяемого заимствования. Следовательно, поведение `&mut` считалось бы одинаковым для всех допустимых типов. Lifetime-аннотация управляет временем хранения данных и может продлить жизнь локального владельца. В результате «Изменяемые ссылки» считали бы безопасным и на путях, которых пример не выполняет. Изменяемая ссылка &mut T предоставляет исключительный доступ к месту на время заимствования: одновременно нельзя иметь вторую активную ссылку к тем же данным. Последнее использование ссылки всегда совпадает с концом лексического блока. Следовательно, для «Изменяемые ссылки» не понадобилось бы явное предусловие. Drop вызывается сборщиком мусора в неопределённый момент после последнего использования значения. Следовательно, поведение `&mut` считалось бы одинаковым для всех допустимых типов.

Вопрос 8 из 20

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

Даже чтение владельца конфликтует с активным &mut, если изменяемая ссылка ещё будет использована; важна фактическая длительность доступа. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта. Если обычный пример работает, вложенный match или замыкание не способны изменить способ перемещения значения. Контракт «Изменяемые ссылки» считался бы одинаковым при любом состоянии входа. Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные. По этой логике отдельная проверка «Изменяемые ссылки» на другом входе считалась бы лишней. Два индекса массива можно считать разными без проверки, если в тестовых данных они различались.

Вопрос 9 из 20

Какая минимальная правка остаётся корректной при изменении входных данных?

fn dangling() -> &String {
    let s = String::from("temp");
    &s
}

Вызвать `drop` для одной из привязок перед `dangling`, не пересматривая, кто должен владеть ресурсом после операции. Убрать mut у владельца; после этого любые ссылки на него можно будет использовать одновременно с изменением данных. Добавить время жизни `'static` к ссылкам вокруг `dangling`, не меняя фактический срок существования владельца. Приписать возвращаемой ссылке время жизни static; одной аннотации достаточно, чтобы данные жили дольше. Вернуть String по значению либо принимать владельца или хранилище снаружи и возвращать ссылку, связанную с его временем жизни.

Вопрос 10 из 20

Какое утверждение о «Неизменяемые ссылки» остаётся верным при смене входных данных?

Последнее использование ссылки всегда совпадает с концом лексического блока. Такое рассуждение переносило бы вывод о «Неизменяемые ссылки» на неисполненную ветвь. Нелексические времена жизни позволяют ссылке пережить уничтожение владельца, когда после блока она используется только для чтения. Тогда поведение «Неизменяемые ссылки» при раннем выходе выводили бы из обычного пути. Drop вызывается сборщиком мусора в неопределённый момент после последнего использования значения. В один момент Rust разрешает любое число общих ссылок &T, пока нет активной изменяемой ссылки к тому же месту. Аннотация времени жизни продлевает существование владельца до конца функции. Следовательно, для «Неизменяемые ссылки» не понадобилось бы явное предусловие.

Вопрос 11 из 20

Какой узкий вывод следует из проверки `String::from`?

fn first<'a>(x: &'a str, _y: &str) -> &'a str { x }
let outer = String::from("outer");
let r;
{
    let inner = String::from("inner");
    r = first(&outer, &inner);
}
println!("{r}");

Код компилируется: возвращаемая ссылка явно связана только с outer, а краткоживущий второй аргумент не влияет на r. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Одного успешного примера достаточно, чтобы считать проверенными и невыполненные ветви контракта. Проверку ошибки для `first` при таком подходе заменили бы успешным примером. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной.

Вопрос 12 из 20

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

let mut data = [10, 20, 30, 40];
let left = &mut data[0];
let right = &mut data[1];
*left += *right;

До выполнения код дойдёт без ошибки компиляции, поскольку деструктор вызывается до выполнения последней строки области. Значит, выполнение должно пройти через `&mut` без изменения сигнатуры. Код не компилируется: индексирование не доказывает borrow checker, что две изменяемые ссылки относятся к разным элементам массива. Код компилируется, а проблема проявляется только при выполнении: нарушение владения обнаруживается паникой уже после начала выполнения. Код компилируется, а проблема проявляется только при выполнении: порядок освобождения выбирается сборщиком мусора во время выполнения. До выполнения код дойдёт без ошибки компиляции, поскольку заимствование прекращается только после явного вызова drop для ссылки.

Вопрос 13 из 20

Где код выходит за границы допустимых типов или заимствований?

fn dangling() -> &String {
    let s = String::from("temp");
    &s
}

Проверка типов пропустит этот путь: любая передача по ссылке требует времени жизни static. Код компилируется, а проблема проявляется только при выполнении: ссылка остаётся допустимой, но чтение может вернуть прежнее или новое значение. Функция не компилируется: она пытается вернуть ссылку на локальную String, которая будет уничтожена до возврата. Проверка типов пропустит этот путь: неизменяемая ссылка сохраняет право на чтение даже во время активного изменяемого заимствования. Компиляция завершится успешно: аннотация времени жизни продлевает существование владельца до конца функции.

Вопрос 14 из 20

Какое правило делает операцию `&mut` некорректной до запуска?

let mut n = 1;
let a = &mut n;
let b = &mut n;
*a += 1;
*b += 1;

Проверка типов пропустит этот путь: заимствование прекращается только после явного вызова drop для ссылки. Фрагмент успешно соберётся: последнее использование ссылки всегда совпадает с концом лексического блока. Код не компилируется: в момент создания b неизменяемое заимствование через a ещё активно и будет использовано позже. Сборка пройдёт, поскольку неизменяемая ссылка сохраняет право на чтение даже во время активного изменяемого заимствования. Код не компилируется: в момент создания b изменяемое заимствование через a ещё активно и будет использовано позже.

Вопрос 15 из 20

Что можно считать доказанным после успешного выполнения `&mut`?

let mut n = 0;
{
    let p = &mut n;
    *p += 2;
}
let q = &mut n;
*q += 3;

Раз тест прошёл, производительность решения тоже можно считать подтверждённой. Дополнительный сценарий вокруг `&mut` при таком толковании уже не требуется. После успешного запуска основной ветви отдельные проверки ошибки, отмены и повторного вызова становятся избыточными. Два изменяемых заимствования допустимы, потому что их области не пересекаются; итоговое значение n равно 5. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы.

Вопрос 16 из 20

Какое описание итогового состояния программы верно?

let text = String::from("rust");
let a = &text;
let b = &text;
println!("{} {}", a.len(), b.len());

Проверка типов завершится ошибкой: заимствование прекращается только после явного вызова drop для ссылки. Сборка пройдёт, поскольку последнее использование ссылки всегда совпадает с концом лексического блока. Код компилируется: несколько неизменяемых ссылок могут одновременно читать одно значение. Компиляция завершится успешно: ключевое слово move создаёт независимую глубокую копию захваченного значения. Код считается допустимым, потому что аннотация времени жизни продлевает существование владельца до конца функции.

Вопрос 17 из 20

Как исправить реализацию, не полагаясь на случайный порядок выполнения?

let mut n = 1;
let a = &mut n;
let b = &mut n;
*a += 1;
*b += 1;

Выполнить изменения последовательно в разных областях или закончить последнее использование a до создания b. Добавить время жизни `'static` к ссылкам вокруг `Изменяемые`, не меняя фактический срок существования владельца. Вызвать `drop` для одной из привязок перед `Изменяемые`, не пересматривая, кто должен владеть ресурсом после операции. Убрать mut у владельца; после этого любые ссылки на него можно будет использовать одновременно с изменением данных. Следовательно, для «Изменяемые ссылки» не понадобилось бы явное предусловие. Клонировать задействованное значение перед `Изменяемые` и не менять отношения владения; лишнюю копию считать приемлемой ценой простого кода.

Вопрос 18 из 20

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

Непересекающиеся по смыслу обращения считаются непересекающимися и без явного разделения данных. Неизменяемая ссылка сохраняет право на чтение даже во время активного изменяемого заимствования. Последнее использование ссылки всегда совпадает с концом лексического блока. Тогда поведение «Правила aliasing» при раннем выходе выводили бы из обычного пути. Безопасный интерфейс должен доказать непересечение изменяемых ссылок; для срезов стандартный способ — split_at_mut. Несколько &mut допустимы, когда программист знает, что адреса различаются; отдельный безопасный интерфейс для доказательства не нужен.

Вопрос 19 из 20

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

let mut data = [10, 20, 30, 40];
let (left, right) = data.split_at_mut(1);
left[0] += right[0];
assert_eq!(data[0], 30);

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

Вопрос 20 из 20

Как правильно прочитать результат диагностического сценария `String::from`?

let mut text = String::from("r");
let view = &text;
println!("{view}");
text.push_str("ust");

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