Трейты — бесплатный тест онлайн

Вопрос 1 из 25

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

struct Post(String);
impl Summary for Post { fn title(&self) -> &str { &self.0 } }
let p = Post("News".into());
assert_eq!(p.line(), "— News");

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

Вопрос 2 из 25

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

trait Summary {
    fn title(&self) -> &str;
    fn line(&self) -> String { format!("— {}", self.title()) }
}

Продублировать реализацию для каждого известного типа вокруг `Summary`, вместо того чтобы исправить границы обобщения «Определение trait». Сделать трейт объектобезопасным удалением всех методов, которые возвращают Self, без альтернативного API. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Клонировать захваченное состояние перед каждым вызовом `Summary`, не уточняя требуемый трейт вызова или время жизни. Заменить текущую форму `Summary` на `Box<dyn Trait>` во всех местах, не проверяя владение, объектобезопасность и стоимость вызова. Формулировать в трейте минимальный устойчивый контракт; производное поведение оставить методом по умолчанию, если оно действительно одинаково для реализаций.

Вопрос 3 из 25

Что нужно изменить вокруг `String::from`, чтобы устранить первопричину?

fn duplicate<T: Clone>(value: &T) -> (T, T) {
    (value.clone(), value.clone())
}
let pair = duplicate(&String::from("x"));

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

Вопрос 4 из 25

На какое правило следует опираться при ревью кода по теме «Ограничения трейтов»?

Trait bound проверяется только при фактическом вызове метода во время выполнения. Следовательно, поведение `String::from` считалось бы одинаковым для всех допустимых типов. Trait bound ограничивает допустимые подстановки T и открывает методы соответствующего трейта внутри обобщённого кода. Blanket impl автоматически разрешает любые пересечения реализаций. Такое рассуждение переносило бы вывод о «Ограничения трейтов» на неисполненную ветвь. Любой трейт можно использовать как dyn Trait без ограничений на методы и Self. По этой логике отдельная проверка «Ограничения трейтов» на другом входе считалась бы лишней. Dyn Trait сохраняет конкретный размер значения внутри типа указателя без косвенности.

Вопрос 5 из 25

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

Любой трейт можно использовать как dyn Trait без ограничений на методы и Self. Тогда поведение «Методы по умолчанию» при раннем выходе выводили бы из обычного пути. Trait bounds проверяются при выполнении, когда конкретный метод впервые вызван. Blanket impl автоматически разрешает любые пересечения реализаций. По этой логике отдельная проверка «Методы по умолчанию» на другом входе считалась бы лишней. Blanket impl всегда имеет меньший приоритет, чем конкретная реализация, поэтому пересечения допустимы. Метод по умолчанию является обычной частью trait API: реализация может его наследовать или переопределить с той же сигнатурой.

Вопрос 6 из 25

Какое свойство закрепляет сценарий `mathlib::square`?

/// Возвращает квадрат.
///
/// ```
/// assert_eq!(mathlib::square(4), 16);
/// ```
pub fn square(x: i32) -> i32 { x * x }

До выполнения код дойдёт без ошибки компиляции, поскольку blanket impl автоматически разрешает любые пересечения реализаций. Пример документации компилируется как doctest при cargo test и одновременно проверяет публичный способ использования функции. Фрагмент не соберётся: метод по умолчанию использует обязательный метод трейта. Пример документации компилируется как doctest при cargo test и одновременно проверяет закрытый способ использования функции. Код компилируется, но ленивый итератор запускает фоновую задачу до терминальной операции. Контракт `square` считался бы одинаковым при любом состоянии входа.

Вопрос 7 из 25

Как исправить участок с `render` без обхода проверки компилятора?

trait Render { fn render(&self) -> String; }
impl Render for String { fn render(&self) -> String { self.clone() } }

Для внешнего трейта и внешнего типа создать локальный newtype и реализовать трейт для него, вместо попытки обойти coherence через небезопасный код. Добавить Clone ко всем trait bounds, даже если реализация использует только ссылки. При каждом таком вызове появляется отдельный владелец и оплачивается копирование данных. По этой логике отдельная проверка `render` на другом входе считалась бы лишней. Заменить текущую форму `Render` на `Box<dyn Trait>` во всех местах, не проверяя владение, объектобезопасность и стоимость вызова. Клонировать захваченное состояние перед каждым вызовом `Render`, не уточняя требуемый трейт вызова или время жизни. Продублировать реализацию для каждого известного типа вокруг `Render`, вместо того чтобы исправить границы обобщения «Реализация».

Вопрос 8 из 25

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

fn duplicate<T: Clone>(value: &T) -> (T, T) {
    (value.clone(), value.clone())
}
let pair = duplicate(&String::from("x"));

Код компилируется: граница Clone разрешает вызвать clone для T и вернуть два владеющих значения. До выполнения код дойдёт без ошибки компиляции, поскольку blanket impl автоматически разрешает любые пересечения реализаций. Из этого следовало бы, что иной порядок операций для `duplicate` ничего не меняет. Компиляция завершится успешно: trait bound проверяется только при фактическом вызове метода во время выполнения. Rust примет этот код, поскольку dyn Trait сохраняет конкретный размер значения внутри типа указателя без косвенности. По этой логике отдельная проверка `duplicate` на другом входе считалась бы лишней. Rust не примет такую запись, поскольку метод по умолчанию использует обязательный метод трейта.

Вопрос 9 из 25

Какой риск остаётся после успешной компиляции кода по теме «Тестирование и инструменты Cargo» в контексте «Трейты»?

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

Вопрос 10 из 25

Какая часть механизма «Ограничения трейтов» зафиксирована тестом `std::fmt::Display`?

fn show<T>(value: &T) -> String
where T: std::fmt::Display + ?Sized
{ value.to_string() }
assert_eq!(show::<str>("rust"), "rust");

Нормальный результат на одном входе позволяет распространить тот же вывод на отмену и частичное выполнение. Контракт `show` считался бы одинаковым при любом состоянии входа. Граница?Sized снимает неявное требование Sized и позволяет явно использовать str за ссылкой. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной.

Вопрос 11 из 25

Как изменится состояние программы после `name`?

trait Named {
    fn name(&self) -> &str;
    fn describe(&self) -> String { format!("item {}", self.name()) }
}
struct User(String);
impl Named for User { fn name(&self) -> &str { &self.0 } }

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

Вопрос 12 из 25

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

/// Возвращает квадрат.
///
/// ```
/// assert_eq!(mathlib::square(4), 16);
/// ```
pub fn square(x: i32) -> i32 { x * x }

# Cargo.toml: package name = "mathlib"
# cargo test --doc

Контракт можно считать подтверждённым самой сборкой; запуск и отрицательные случаи не обязательны. Проверку ошибки для `square` при таком подходе заменили бы успешным примером. Команда отдельно запускает документационные тесты и обнаружит пример, который перестал компилироваться после изменения публичного API. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Дополнительный сценарий вокруг `mathlib::square` при таком толковании уже не требуется. Одного успешного примера достаточно, чтобы считать проверенными и невыполненные ветви контракта. Контракт `square` считался бы одинаковым при любом состоянии входа. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки.

Вопрос 13 из 25

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

Если generic-код компилируется для одного типа, скрытые ограничения для других типов невозможны. По этой логике отдельная проверка «Ограничения трейтов» на другом входе считалась бы лишней. Переход с impl Trait на dyn Trait не меняет владение, layout и стоимость вызова. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Из этого следовало бы, что иной порядок операций для «Ограничения трейтов» ничего не меняет. Связка T: Trait + Send относится к самому T, а не автоматически к связанным типам и ссылкам; необходимые ограничения нужно выразить на точных компонентах. Ассоциированный тип и параметр типа взаимозаменяемы для всех контрактов вызывающего кода. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Размер машинного кода не меняется при росте числа мономорфизаций. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Поэтому ошибочный сценарий вокруг «Ограничения трейтов» не проверяли бы отдельно.

Вопрос 14 из 25

Какие значения останутся доступными после `title`?

trait Summary {
    fn title(&self) -> &str;
    fn line(&self) -> String { format!("— {}", self.title()) }
}

Компиляция завершится успешно: dyn Trait сохраняет конкретный размер значения внутри типа указателя без косвенности. Код пройдёт проверку компилятора: trait bound проверяется только при фактическом вызове метода во время выполнения. Компиляция завершится успешно: обобщённая функция использует один общий машинный код с динамическим поиском всех методов. Компилятор отвергнет фрагмент, поскольку метод по умолчанию использует обязательный метод трейта. Трейт объявляет обязательный метод title и предоставленный метод line, который может вызывать обязательный метод через &self.

Вопрос 15 из 25

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

Trait bound проверяется только при фактическом вызове метода во время выполнения. Проверку ошибки для «Определение trait» при таком подходе заменили бы успешным примером. Trait bounds проверяются при выполнении, когда конкретный метод впервые вызван. Следовательно, для «Определение trait» не понадобилось бы явное предусловие. Трейт задаёт общий интерфейс поведения; сигнатуры обязательных методов проверяются у каждой реализации, а методы с телом доступны по умолчанию. Любой трейт можно использовать как dyn Trait без ограничений на методы и Self. Следовательно, поведение `title` считалось бы одинаковым для всех допустимых типов. Обобщённая функция использует один общий машинный код с динамическим поиском всех методов. Тогда различия между обычным и граничным случаем для «Определение trait» исчезли бы.

Вопрос 16 из 25

Какое утверждение о «Тестирование и инструменты Cargo» остаётся верным при смене входных данных в контексте «Трейты»?

cargo test запускает unit-, integration- и documentation tests; doctest особенно полезен для проверки публичных сигнатур и примеров. Blanket impl автоматически разрешает любые пересечения реализаций. Следовательно, поведение `mathlib::square` считалось бы одинаковым для всех допустимых типов. Trait bounds проверяются при выполнении, когда конкретный метод впервые вызван. Тогда различия между обычным и граничным случаем для «Тестирование и инструменты Cargo» исчезли бы. Проверку ошибки для «Тестирование и инструменты Cargo» при таком подходе заменили бы успешным примером. Move определяет только потокобезопасность замыкания и не влияет на способ захвата. Следовательно, поведение `mathlib::square` считалось бы одинаковым для всех допустимых типов. Fn, FnMut и FnOnce выбираются программистом явной аннотацией, а не способом использования захватов.

Вопрос 17 из 25

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

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

Вопрос 18 из 25

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

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

Вопрос 19 из 25

Как убрать скрытое предусловие вокруг `name`, сохранив исходный замысел?

trait Named {
    fn name(&self) -> &str;
    fn describe(&self) -> String { format!("item {}", self.name()) }
}
struct User(String);
impl Named for User { fn name(&self) -> &str { &self.0 } }

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

Вопрос 20 из 25

Что показывает `A::value` применительно к механизму «Методы по умолчанию»?

trait A { fn value(&self) -> i32 { 1 } }
trait B { fn value(&self) -> i32 { 2 } }
struct X;
impl A for X {}
impl B for X {}
assert_eq!(A::value(&X) + B::value(&X), 3);

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

Вопрос 21 из 25

Какая часть механизма «Реализация» зафиксирована тестом `std::fmt::Display`?

struct LocalString(String);
impl std::fmt::Display for LocalString {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { self.0.fmt(f) }
}

Если основной путь стабилен, ранний выход и повторный вход можно не воспроизводить отдельно. Проверку ошибки для `fmt` при таком подходе заменили бы успешным примером. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Дополнительный сценарий вокруг `std::fmt::Display` при таком толковании уже не требуется. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Newtype является локальным типом, поэтому реализация внешнего Display допустима и не нарушает orphan rule.

Вопрос 22 из 25

Как изменить фрагмент с `mathlib::square`, не перенося ошибку на время выполнения?

/// Возвращает квадрат.
///
/// ```
/// assert_eq!(mathlib::square(4), 16);
/// ```
pub fn square(x: i32) -> i32 { x * x }

Для публичного трейта сочетать модульные тесты реализаций, интеграционные тесты внешнего API и doctest-примеры, которые импортируют crate как пользователь. Заменить текущую форму `mathlib::square` на `Box<dyn Trait>` во всех местах, не проверяя владение, объектобезопасность и стоимость вызова. Клонировать захваченное состояние перед каждым вызовом `mathlib::square`, не уточняя требуемый трейт вызова или время жизни. Продублировать реализацию для каждого известного типа вокруг `mathlib::square`, вместо того чтобы исправить границы обобщения «Тестирование и инструменты Cargo». Добавить Clone ко всем trait bounds, даже если реализация использует только ссылки. При каждом таком вызове появляется отдельный владелец и оплачивается копирование данных. Следовательно, для `square` не понадобилось бы явное предусловие.

Вопрос 23 из 25

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

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

Вопрос 24 из 25

Что Rust гарантирует при корректном использовании «Реализация»?

Любой трейт можно использовать как dyn Trait без ограничений на методы и Self. Blanket impl всегда имеет меньший приоритет, чем конкретная реализация, поэтому пересечения допустимы. Тогда поведение «Реализация» при раннем выходе выводили бы из обычного пути. Dyn Trait сохраняет конкретный размер значения внутри типа указателя без косвенности. Blanket impl автоматически разрешает любые пересечения реализаций. Тогда различия между обычным и граничным случаем для «Реализация» исчезли бы. Правила coherence запрещают конфликтующие реализации; в общем случае impl допустим, когда текущему crate принадлежит реализуемый трейт или подходящий локальный тип.

Вопрос 25 из 25

Какое состояние получится после всех действий с `render`?

trait Render { fn render(&self) -> String; }
impl Render for String { fn render(&self) -> String { self.clone() } }

Такая реализация допустима только если trait Render объявлен в текущем crate: правило orphan требует локальности трейта или типа. Сборка пройдёт, поскольку trait bound проверяется только при фактическом вызове метода во время выполнения. Код пройдёт проверку компилятора: dyn Trait сохраняет конкретный размер значения внутри типа указателя без косвенности. Rust примет этот код, поскольку blanket impl автоматически разрешает любые пересечения реализаций. Тогда поведение `render` при раннем выходе выводили бы из обычного пути. Rust не примет такую запись, поскольку метод по умолчанию использует обязательный метод трейта. Тогда различия между обычным и граничным случаем для `render` исчезли бы.