Describe Rust's orphan rule and its ecosystem purpose

WHAT THIS TESTS: This question probes whether you understand trait coherence as a global property rather than a local convenience. The interviewer wants to see that you recognize why Rust forbids implementing a foreign trait for a foreign type and how this scales to an ecosystem of thousands of crates. It separates candidates who memorize syntax from those who can reason about distributed system invariants in a language design context.

A GOOD ANSWER COVERS: First, state the rule precisely: in a trait implementation, at least one of the trait or the implementing type must be defined in the current crate. Second, connect this to coherence: the compiler must be able to pick exactly one implementation for any trait and type pair anywhere in the dependency graph. Third, explain the crates.io scenario: if crate A and crate B both depend on standard library types and traits but are otherwise unrelated, they could both add impl Trait for Type, and any crate C that depends on both A and B would see a conflict with no resolution path. Fourth, mention that this rule avoids silent breakage when upstream crates add new impls, because only the crate owning the trait or type can authorize new implementations.

COMMON WRONG ANSWERS: A red flag is claiming the orphan rule exists only to stop name collisions or to protect private fields. Another is saying you can work around it with newtype wrappers but failing to explain why the workaround is necessary in the first place. Some candidates describe the rule as an arbitrary restriction that makes generic programming harder; this signals a lack of systems thinking. Confusing the orphan rule with the overlap rule is also common but distinct.

LIKELY FOLLOW-UPS: An interviewer might ask how the newtype pattern sidesteps the orphan rule and what ergonomic costs it imposes. They might probe whether you know about the relaxed orphan rules for fundamental types like references or tuples. Another follow-up is asking how negative impls or specialization interact with coherence. You might also be asked to compare Rust's approach with Haskell's type class instance rules.

ONE CONCRETE EXAMPLE: Imagine you are writing a web framework crate and want to implement serde's Serialize trait for the standard library's TcpStream. Without the orphan rule, your crate could provide impl Serialize for TcpStream. Meanwhile, a logging crate in the same dependency tree could also provide impl Serialize for TcpStream. A downstream application using both your framework and that logger would fail to compile with conflicting implementations, and neither crate could fix it without breaking their own API contracts. The orphan rule forces you to wrap TcpStream in a local newtype, making the implementation explicit and scoped to your crate.