Why 'externalized' proofs of cyclic trait impls does not work

There are two primary approaches to handling supertraits: modular proofs and external proofs. Modular proofs involve the implementation establishing that all supertraits hold, while external proofs require the code using the implementation to prove the supertraits. The author argues that external proofs are incompatible with Rust and that modular proofs are the only viable solution for cyclic trait impls.

Modular proofs are considered better because they allow each part of the program to be independently checked, which helps in maintaining soundness. However, there is a concern that recursive reliance on the implementation itself could prove the supertraits, leading to invalidity. To avoid this issue, a rule is needed that explicitly prohibits recursive reliance on the implementation during the proof process.

On the other hand, the external proof approach presents an awkward situation where the implementation is not responsible for proving the supertraits. Instead, the implementation only establishes a shallow association, and the supertraits must be proven separately. While this approach prevents the impl from being used to falsely prove the supertraits, it makes the implementation less reliable and harder to trust.

The author concludes that, given the potential incompatibility of external proofs with Rust's design, particularly in the context of unsafe traits, modular proofs are the only practical solution for handling cyclic trait impls.