Компилятор Rust обеспечивает соблюдение правила сироты (основной компонент системы согласованности), чтобы гарантировать, что каждая пара трейта и типа имеет не более одной реализации по всей графике зависимостей. Это правило требует, чтобы блок impl был действителен, только если либо реализуемый трейта, либо получаемый тип определены в текущем крете, называемом "локальным" кретом. Запрещая реализации, в которых и трейта, и тип являются внешними, Rust предотвращает ситуации, когда два независимых крейта могут ввести конфликтующие реализации для одного и того же объекта, что может привести к неопределенному поведению или неразрешимым неоднозначностям в downstream проектах. Исключение "локального типа" разрешает разработчикам реализовать внешний трейта для локального типа (что позволяет использовать стандартные операторы на пользовательских структурах) или локальный трейта для внешнего типа (что позволяет использовать методы расширения), обеспечивая однозначную мономорфизацию и нулевую стоимость абстракции без таблиц динамической диспетчеризации.
Наша команда разрабатывала высокопроизводительную библиотеку сервера GraphQL, которая должна была сериализовать определения схемы в JSON с использованием фреймворка serde. Нам нужно было реализовать трейта Serialize от serde для нашей локальной структуры Schema, что было довольно просто, так как тип был локальным. Однако нам также требовалось выполнить собственное форматирование для типа Document из внешнего крета graphql_parser, чтобы интегрировать его в нашу систему логирования через стандартный трейта Display. Это создало дизайнерское напряжение, так как и Document, и Display были внешними, и мы опасались будущих нарушений, если основной крет добавит свою собственную реализацию Display, потенциально создавая нарушение согласованности для наших пользователей.
Первым решением, которое мы рассмотрели, был паттерн Newtype, обертывание graphql_parser::Document в структуру кортежа struct DocWrapper(graphql_parser::Document) и реализация Display для DocWrapper.
Этот подход полностью уважает правило сироты, потому что DocWrapper является локальным типом, и Rust гарантирует нулевую стоимость абстракции для новых типов без накладных расходов во время выполнения. Это позволяет нам сохранить полный контроль над API и предотвращает любые будущие конфликты на стороне основного крета. Однако это вводит значительное количество шаблонного кода для преобразований и ухудшает эргономику, так как пользователям необходимо вручную оборачивать экземпляры или полагаться на предоставленные реализации From, потенциально загромождая публичное API типами обертки, которые раскрывают детали реализации.
Второе решение заключалось в создании расширяющего трейта GraphQLDisplay, определенного локально в нашем крете, и его реализации непосредственно для внешнего типа Document.
Это законно в соответствии с правилом сироты, потому что сам трейта является локальным, даже если тип является внешним, и это избегает эргономических трений типов-оберток, позволяя синтаксис цепочек методов. Критическим недостатком является то, что это не интегрируется со стандартными макросами форматирования Rust, такими как format! или println!, которые требуют трейта Display; пользователям нужно будет импортировать наш пользовательский трейта и вызывать конкретный метод, создавая разрозненный опыт, не соответствующий стандартным соглашениям Rust.
В конечном итоге мы выбрали паттерн Newtype для типа Document, потому что долгосрочная стабильность и интеграция со стандартной библиотекой перевесила краткосрочные эргономические затраты. Используя DocWrapper, мы гарантировали, что наша обработка ошибок может использовать стандартные инструменты форматирования без пользовательских макросов или импортов трейтов. Для типа Schema мы просто извели Serialize, так как и тип, и макрос извлечения были локальными. Результатом стал согласованный, защищенный от будущих изменений API, где все разрешения трейтов были однозначными на этапе компиляции, компиляция оставалась быстрой из-за отсутствия накладных расходов на разрешение неоднозначностей, и мы исключили риск проблем алмазной зависимости, если graphql_parser когда-либо введет свою собственную реализацию Display.
Как правило сироты распространяется на обобщенные типы, такие как Vec<T>, и почему разрешена реализация внешнего трейта для Vec<LocalType>, в то время как Vec<ForeignType> запрещена?
Правило сироты применяется к обобщенным типам через концепцию "покрытия локального типа", которая требует, чтобы по крайней мере один параметр типа внутри обобщенной структуры был локальным для текущего крета. Таким образом, impl ForeignTrait for Vec<LocalType> является действительным, потому что LocalType привязывает реализацию к локальному крету, гарантируя, что ни один другой крет не может написать конфликтующую реализацию для этого конкретного конкретного типа. Напротив, impl ForeignTrait for Vec<ForeignType> нарушает правило, потому что и трейта, и все аргументы типов являются внешними, создавая риск того, что крет, определяющий ForeignType, позже может реализовать тот же трейта для Vec<ForeignType>, что приведет к конфликтам согласованности. Кандидаты часто упускают из виду, что это покрытие применимо рекурсивно к вложенным обобщенным типам, но не распространяется на сам обобщенный контейнер, если только этот контейнер также не определен локально.
Почему общее внедрение (например, impl<T> Trait for T where T: ToString) в верхнем крете предотвращает возможности последующих кретов реализовывать этот трейта для конкретных типов, даже локальных?
Общее внедрение предоставляет поведение по умолчанию для всех типов, удовлетворяющих определенным ограничениям трейта, и правила согласованности Rust запрещают любое конкретное внедрение, которое перекрывает существующее общее внедрение. Если верхний крет предоставляет impl<T> Serialize for T where T: ToString, последующие креты не могут реализовать Serialize для любого типа, который реализует ToString, даже если этот тип локален, потому что компилятор не может гарантировать, что общее внедрение и конкретное внедрение являются взаимно исключающими. Это отличается от правила сироты; в то время как правило сироты регулирует кто может написать реализацию, правило перекрытия регулирует, могут ли два действительных внедрения сосуществовать в одном пространстве имен. Кандидаты часто путают эти концепции, пытаясь написать конкретные внедрения, которые синтаксически действительны согласно правилам сироты, но отклоняются из-за перекрытия с общими внедрениями вверх по течению.
Какое особое обращение получают фундаментальные трейты, такие как Fn, FnMut и FnOnce, в отношении правила сироты, и почему это позволяет замыканиям реализовывать эти трейты без нарушения согласованности?
Семейство трейтов Fn обозначается как "фундаментальные", что смягчает правило сироты, позволяя реализации этих трейтов для внешних типов, когда реализация включает локальные типы в обобщенных параметрах трейта. Это "обратное" правило по сутиTreats the trait as local for coherence purposes when determining if an implementation is allowed. Например, замыкание, определенное в вашем крете, имеет уникальный, неназванный тип, который локален для вашего крета, и разрешение FnOnce для этого замыкания допустимо, даже если FnOnce определен в стандартной библиотеке, и тип замыкания является непрозрачным. Кандидаты часто упускают этот механизм, потому что это деталь реализации того, как Rust обрабатывает замыкания, но понимание этого проясняет, почему замыкания могут захватывать локальные окружения и реализовывать внешние трейты без необходимости новых оберток типов или вызова ошибок согласованности.