sparksoli.blogg.se - External coherence meaning

For each type parameter Pj found before that, the function checks that it does not contain any of the placeholder types T0…Tn at any level. The function goes through each input type from P0 to Pn looking for the first local type Pi. The parameters P0…Pn are known as the input types of the trait. The orphan_check_trait_ref function takes a trait ref which is essentially Trait and its parameters P0…Pn (notice that the Self type P0 is included).

No type parameters T1.Tn may appear in the type parameters that precede Pi (that is, Pj where j Trait for P0.At least one type must meet the LT pattern defined above.Given an impl impl Trait for P0, either Trait must be local to the current crate, or: The orphan rules as proposed in that RFC are as follows: Of all of these, RFC 1023 is probably considered the most authoritative source on the orphan rules. E0210: A violation of the orphan rules in the Rust Error Index.Trait Implementation Coherence in the Rust Reference.There are several resources which can be used to figure out the orphan rules in rustc. In order to model the orphan check in chalk, we need a precise description of the orphan rules as they are implemented in rustc today. Upstream impls are not checked with this rule. This check is applied to all impls in the current crate. We want to capture some rule: Given impl for Trait for P0, LocalImplAllowed(P0: Trait) is true if and only if this impl is allowed in the current (local) crate. This check is what makes it impossible for other crates to define impls of your traits for your types. The purpose of the orphan check is to ensure that an impl is only definable in a single crate.

Downstream crates are allowed to assume that upstream crates will not add any semver incompatible impls.

Property: Upstream crates must assume that downstream crates will add any impls that compile.

Axiom 2: crates downstream from you should be able to implement your traits.

Axiom 1: crates upstream to you should be able to implement their own traits for their own types.

Historical Note: We used to use the term “external” instead of “upstream”.

Type classes: confluence, coherence and global uniqueness.

compatible - any semver compatible world.

overlap check - ensures that no two impls overlap in your program or in any compatible world.

A consequence of the orphan rules: for every impl that could exist, it only exists in one place - this is key to having a coherent system.

orphan check - ensures that each impl abides by the orphan rules, or in other words, that an impl is potentially implementable by the crate adding it.

To check for coherence, the Rust compiler completes two separate but related checks:

To this end, the orphan rule intuitively says “either the trait must be local or the self-type must be local”. However, if you define your own trait MyTrait, then you can implement MyTrait for any type you like, including external types like Vec.

But you can implement Display for MyType, because you defined MyType. So continuing our simple example of Display, if you are defining your own library, you could not implement Display for Vec, because both Display and Vec are defined in the standard library. The role of the orphan rules in particular is basically to prevent you from implementing external traits for external types. So if we think of the trait Display, we want to guarantee that if we have a trait reference like MyType : Display, we can uniquely identify a particular impl. The idea of trait coherence is that, given a trait and some set of types for its type parameters, there should be exactly one impl that applies. It was copy-pasted here on, but has not been vetted for accuracy of the current implementation or edited for clarity. This document was previously prepared for the initial design of coherence rules in Chalk.