# Trying to understand a paragraph in Coherence Rule

In this article, there is a paragraph that I don't quite understand:

All types `Pj` such that `j < i` do not contain `T0…Tn` at any level of depth (i.e. the types are fully visible “visible” meaning that the type is a known type and not a type parameter or variable)

In particular, `j < i`. It feels arbitrary and asymmetrical. Why not `j > i` instead? And why not `j != i`?

Writing it as `j < i` is the same as `j > i`, because in this case they are symmetric. If we write it as `j != i`, then it must be such that all `T0..Tn` must "belong" to `Pi`, which is not the condition that you want. What you want is that the ability to order `P0..Pn` such that that:

``````P0  ...........  Pi - 1            Pi               Pi+1  .......... Pn
^^^^^^^^^^^^^^^^           ^^^^^^^^^              ^^^^^^^^^^^^^^^^
These types don't involve      This is in             These may involve
T0..Tn              current crate                 T0..Tn
``````

Hence, the condition `j < i`.

I understand that `j < i` refers to the `P` before `Pi`. What I don't understand is: Why only `P` before `Pi` are not allowed to involve `T`? Why not also `P` after `Pi`? Is there any other rule that I'm not paying attention to?

I explained it above.

Your explanation needs an explanation, too.

What @RedDocMD meant: Rust could have picked `i < j` rule or it could have picked `j < i` rule, but `i != j` rule wouldn't work.

Choice between `i < j` and `j < i` was more-or-less arbitrary.

1 Like

Can you go more in depth? How exactly `i != j` don't work?

You can read about that in an RFC which changed these rules.

It explains what change to the rules needed to accomplish (while still ensuring that two crates can not introduce conflicting implementations).

1 Like

Nice explanation.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.