Can not impl trait from another crate for Vec<T> with T from this crate

[SimonSapin]

Test case:

a.rs

pub trait Foo {}

b.rs

extern crate a;
struct Bar;
impl a::Foo for Vec<Bar> {}
fn main() {}

In rustc 1.1.0-nightly (90cc830 2015-04-22) (built 2015-04-23):

$ rustc --crate-type lib a.rs
$ rustc -L . a.rs
a.rs:3:1: 3:28 error: the impl does not reference any types defined in this crate; only traits defined in the current crate can be implemented for arbitrary types [E0117]
a.rs:3 impl b::Foo for Vec<Bar> {}
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

Note the impl does not reference any types defined in this crate. This is not true, Bar is defined is this crate.

This indicates a bug either in the coherence rules (this program should be valid and the error not be shown) or in the error message, which is misleading.

CC @nikomatsakis

[SimonSapin]

In either case, the work-around / fix is to make a new type that wraps Vec<Bar> and implement the trait on that.

[ftxqxd]

I think this is an intentional result of #23086 (RFC 1023).

[Diggsey]

I think the rationale is so that Vec<_> could be made to implement the trait later on without breaking backwards compatibility (it would conflict with your implementation of the trait otherwise).

[SimonSapin]

@Diggsey by “later on”, do you mean “in a future version of the crate that defines Vec?” Ok, that’s understandable. In that case, this issue is about reformulating the error message.

[Ryman]

This error now provides a link to a detailed explanation of E0117 so this issue might be considered fixed?

[GildedHonour]

what's the reason for this restriction in the 1st place?

[zbraniecki]

An example use case for this:

I have a library that implements an AST, Parser and Serializer for a given DSL. I'd like to keep it lean because that's what people will bundle.

I want to have a separate crate that adds serde and allows to serialize and deserialize the AST to/from json.

I think that this limitation prevents me from being able to do that.

[sinkuu]

If this is allowed, adding implss become a breaking-change, because any other crate could potentially have an conflicting impl. We need to bump minor version (or major version if >1.0.0) of a crate for every addition of trait impl. Moreover, as standard library is generally not allowed to make breaking-change, we can't implement existing std traits for existing std types anymore.

if your concern is the additional dependencies, you can use features.

[zbraniecki]

Sure, features are one option, but if I don't want to mess with the original package and keep it clean, I just end up with something like this:

https://github.com/zbraniecki/fluent-json-rs/blob/99a2b3e08306fe9b298769e0fbe3abf458e9c69e/src/lib.rs

which is a clone of https://github.com/projectfluent/fluent-rs/blob/70b5e8d387f3b836032b42c997c359263b21c8d0/src/syntax/ast.rs

but with From/Into. (to serialize FTL->AST->JSON and JSON->AST->FTL back).

I'm wondering if it would be possible to write code to automate the creation of a clone of a struct/enum from another crate. Then one could add Serialize/Deserialize on those local struct/enums.

Another option would be to mark structs/enums as extensible by other crates, which would allow the author to decide that he wants to let others impl features for them. That would work better in my case, because it would remove the step of converting from fluent::syntax::ast::* into fluent_json::ast::* back and forth.

[oberien]

I think the rationale is so that Vec<_> could be made to implement the trait later on without breaking backwards compatibility (it would conflict with your implementation of the trait otherwise).

With specialization this is not an issue anymore. If some library implements Foo for Vec<T> and I implement Foo for Vec<Bar> then with specialization both can co-exist and mine will be executed. Therefore I think that allowing implementations of traits for a type not defined in your crate but with a generic parameter from your trait could be allowed again. Do I miss another problem?

[nikomatsakis]

This indicates a bug either in the coherence rules (this program should be valid and the error not be shown) or in the error message, which is misleading.

The bug is in the error message, which I agree is misleading. It's also true that it might be nice to rejigger the rules in this area, but that's a fairly complex undertaking.