Incorrect description of Coherence
Centril opened this issue · comments
In Rust, "trait coherence" (or simply "coherence") is the property that there is at most one implementation of a trait for any given type.
Coherence is not a Rust invention. At the very least, Rust has gotten much of its notion of traits and implementations from Haskell's type classes and instances. Haskell guarantees coherent type classes instances, but it does not guarantee "global uniqueness of instances", which I think is what is described above.
See: http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uniqueness/
That specific blog post is actually the reason I added "In Rust" to that sentence; it seemed like it was giving a significantly different definition of "coherence" in the context of Haskell. I wasn't trying to imply that Rust invented the concept, only that the term may be used differently in other language communities.
I understood that "Rust" was intentional.
However... I'm saying that the use of the word should be uniform in language communities to avoid confusion and so that we may talk to each other. I think it is unambiguous and right to say that Rust guarantees Confluence, Coherence, and Global uniqueness of implementations (up to specialization, which does allow for overlap, but at least preserves coherence given Aaron's specialize modality).
EDIT: In fact, is global uniqueness of instances even an invariant that unsafe code may assume? It seems to me that:
This property states that every different valid typing derivation of a program leads to a resulting program that has the same dynamic semantics.
is exactly what unsafe may assume as an invariant and what is important for soundness?
Hm, I see what you mean, but I'm not sure I want to go against the established usage in what seems to be all past Rust RFCs that talk about "coherence". Plus, I honestly don't understand the distinction between confluence, coherence and global uniqueness; the definitions given by that blog post are meaningless to me (I know enough type theory to recognize the terms used in the definitions, but without a rigorous axiomatization of Rust to refer to I don't know how to actually apply those words to anything). It's not even obvious to me that those distinctions exist in Rust (is "constraint solving" a thing that we do? I don't know Haskell that well).
Ah, is the key distinction that "just coherence" means that any given context only has one impl available, but different contexts might have different impls? Sort of like "local uniqueness" rather than "global uniqueness"?
Found a Scala design discussion that explicitly uses the terms "global coherence" and "local coherence". "Global coherence" is certainly less of a mouthful than "global uniqueness of instances", and the relationship between "global coherence" and "local coherence" is pretty obvious from the terms themselves (if I'm not completely misunderstanding all of this). Do you know if Haskell people would recognize those terms?