Cylic trait implementations: motivation

Summary

The post introduces the problem of cyclic trait implementations in Rust, showing how allowing certain cycles could enable “perfect derive” that derives traits based on field types rather than generic bounds. It also explains why naïvely accepting any cycle is unsound, especially with supertraits, and outlines the need for a principled solution.

• Cyclic trait implementations are currently disallowed; permitting them could let derives generate bounds based on field types (perfect derive).
• Naïve acceptance of any cyclic proof breaks soundness, as demonstrated by a Magic:Copy example that would incorrectly prove String is Copy.
• Existing derives often add unnecessary where‑clauses (e.g., List<T>: Clone requiring T: Clone) which could be avoided with cyclic solving.
• The author distinguishes “good” cycles (e.g., List Clone) from “bad” tautological cycles and plans to use logical tools like coinduction to enforce the difference.

Rust compiler and library authors need a safe way to support cyclic trait solving to improve derive ergonomics without compromising type‑system soundness.