Relax Trait Coherence rules to allow the implementation of a trait on generic types where the type must impl another trait owned by the current crate

[jnicholls]

The title is lengthy, but it boils down to this:

If I have a trait MyRead and I want to implement Read for all T: MyRead, I should be able to do so because I own MyRead and the impl of Read would (should?) only come into scope for type T: MyRead if and only if MyRead is also in scope.

There must be a major hole I am missing, but this would seriously reduce code in a lot of libraries, i.e. implementing traits onto owned types individually.

[ruuda]

That would not work: suppose I define a type T in a new crate my_crate. Then I can implement your_crate::MyRead and std::io::Read for it. MyRead does not have to be in scope for this. Now in a third crate, I use my_crate::T, use std::io::Read, and use your_crate::MyRead. Now there would be two conflicting implementations of io::Read.

[jnicholls]

Hey, I didn't say it was perfect :) It could definitely work if we have a mechanism to explicitly specify which implementation to use. That'll come one day, because there's going to be a lot of ask for it.

[ruuda]

If you have a way to tell the compiler which implementation to use, I think you could circumvent all coherence rules and have multiple trait implementations for a type. Then a user of conflicting implementations would have to resolve the ambiguity, and this means that linking a new crate can cause a compile error. As described here, it was an explicit goal to avoid these problems. (Note that this does not mean these goals cannot change, I believe the point about overloading does not hold in Rust 1.0.0 due to multidispatch.)

[glaebhoerl]

This would be probably be OK with some form of sealed traits though.

[aldanor]

Looks like something like sealed traits would work here indeed – there were a few preceding RFCs as well but they all seemed to be closed or died off.

[Restioson]

Sorry for the necro, but with regards to 'which impl to choose', one could restrict the generic implementation to being a default implementation (specialisation)