|
|
|
|
|
by chrismorgan
2915 days ago
|
|
To elucidate on this: Rust’s trait implementation coherence rules ensure structurally that there is never any ambiguity to be resolved. If I `impl<T: MyTrait> Add<T> for MyType`, I am then barred from writing `impl Add<AnotherType> for MyType` if AnotherType implements MyTrait, as that would cause a conflict, but I am permitted to if it does not, because there is then no conflict. Also you can’t implement any form of Add for MyType from your crate, because you can only implement traits from your own crate on any type, or traits from any trait on your own type, not traits from other crates for types from other crates. (I’m still simplifying this a little, because specialisation is a thing which does allow overlapping implementations, but it must be opted into by the broad implementation by writing `default fn` instead of `fn`.) |
|
http://play.rust-lang.org/?gist=566c7ddb5ec90836004a2549aa78...
Because `impl Add<Bar>` and `impl Add<Baz>` are two clearly different impls there is no ambiguity (RHS is known at compile time).
What specialization would solve is this kind of ambiguity:
http://play.rust-lang.org/?gist=34142671953f75f0448b03bb804f...
Because `impl<T: Debug> Add<T>` and `impl Add<Baz>` are conflicting, since Baz is `:Debug` so both impls apply for a Baz RHS.