Update coherence and orphan rules documentation to match RFC 2451

[ohadravid]

As part of stabilizing RFC 2451 (re-rebalance coherence) in rust-lang/rust#65879, I wanted to update the reference to match it.

I copied the relevant parts of the RFC, with a slight rewording by @nikomatsakis (comment).

[Centril]

This entire paragraph is irrelevant. Haskell (mainly) and other languages are only interesting for the purposes of "influences".

[Centril]

I think this text should mainly explain that overlap is prevented (and the rules for that) and that orphans are not allowed (and the rules for that).

Question to @nikomatsakis: is the orphan rule actually part of preventing overlap in the compiler?

[ohadravid]

Hi @Centril!

I made the changes you requested, and since all the terms seemed relevant I moved all of them to the glossary, making the coherence explanation much shorter so I moved it back to where it was. If you think this is too much for the glossary I can also move them back/move only some of them/etc.

Your question to Niko about the orphan rule/overlap is still relevant, because the old text is not too specific there either (I changed it back to the way it was).

One question about defining fundamental types: I looked for the attribute, and saw that Pin was added since the RFC (So I added it to the list).
Generator is also there, but I didn't add it because it is unstable.
So should there be a sentence like "the lang may define additional types which are considered fundamental"?

[nikomatsakis]

@ohadravid thanks for doing this!

[Centril]

Some points & questions (which @nikomatsakis may help with):

• & and friends are not types; they are type constructors.

• Suppose we have #[fundamental] struct W<P0, P1> { ... }. How would W<A0, A1> behave with respect to locality? In this case the addition of a second type parameter is intentional so that we can suss out the essence of how fundamental types behave. It seems lifetimes have no effect on locality.

• Before itemizing the list of fundamental types it would be good to give a definition of how such types behave.

• What about fundamental traits?

[Centril]

If you think this is too much for the glossary I can also move them back/move only some of them/etc.

No it's good. :)

So should there be a sentence like "the lang may define additional types which are considered fundamental"?

I think we sorta want to give a description of behavior for any arbitrary fundamental type that is semi-syntactic in that it talks about type arguments and type constructors and how those relate wrt. locality and such. Then we can itemize a list of fundamental type constructors.

[ohadravid]

I applied all your edits @Centril , also edited some more title case -> sentence case and such.

I changed the fundamental types part to use the type constructor wording, but I leave it to Niko to define what they are :)

I did use the order of: what are fundamentals, itemized list, locality.
Explaining it with locality first didn't sound right (you have to use at least &T and Box<T> when explaining locality, because of the different syntax, and than it seems like &mut T and Pin are somehow different..) but that's all more like a placeholder until we have the actual description.

[ohadravid]

@Centril @nikomatsakis I used Niko's definitions from RFC 1023.
They seem to fit the reference, but I wasn't too sure if more explanation is needed. I also added the definition of fundamental traits for completeness.

[Centril]

Filed #714 for any follow-ups to the more formal spec.

[Centril]

Thanks!