|
/// 3. For non-`#[fundamental]` traits, they guarantee that parent crates can |
|
/// add "non-blanket" impls without breaking negative reasoning in dependent |
|
/// crates. This is the "rebalancing coherence" (RFC 1023) restriction. |
|
/// |
|
/// For that, we only a allow crate to perform negative reasoning on |
|
/// non-local-non-`#[fundamental]` only if there's a local key parameter as per (2). |
|
/// |
|
/// Because we never perform negative reasoning generically (coherence does |
|
/// not involve type parameters), this can be interpreted as doing the full |
|
/// orphan check (using InCrate::Local mode), substituting non-local known |
|
/// types for all inference variables. |
|
/// |
|
/// This allows for crates to future-compatibly add impls as long as they |
|
/// can't apply to types with a key parameter in a child crate - applying |
|
/// the rules, this basically means that every type parameter in the impl |
|
/// must appear behind a non-fundamental type (because this is not a |
|
/// type-system requirement, crate owners might also go for "semantic |
|
/// future-compatibility" involving things such as sealed traits, but |
|
/// the above requirement is sufficient, and is necessary in "open world" |
|
/// cases). |
The sentence
For that, we only a allow crate to perform negative reasoning on non-local-non-#[fundamental] only if there's a local key parameter as per (2).
Has a weirdly placed “a” and twice “only”. I’m not immediately sure how to best fix it without changing the meaning to something that isn’t meant.
Found while doing #88230
@rustbot label T-compiler
I suppose it might be correct as
/// For that, we only allow a crate to perform negative reasoning on
/// non-local-non-`#[fundamental]` if there's a local key parameter as per (2).
but it would be nice to get confirmation from someone who knows what this comment is talking about.
