-
Notifications
You must be signed in to change notification settings - Fork 13.3k
[E0207] thrown even though T is used in associated type #22834
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Byron
added a commit
to Byron/depot
that referenced
this issue
Feb 26, 2015
This is intended behavior: The idea behind associated types is that they are uniqly determined by impl<A,B> SomeTrait<Option<B>> for Foo<A> {
type Output = Result<A, IoError>;
}
// Foo<A>::Output is different for each A
struct Bar<T> {
_m: PhantomData<T>
}
// Bar<T>::Maker is different for each T If you want to allow many possible types for the same use std::default::Default;
trait Maker<Item> {
fn make(&mut self) -> Item;
}
struct Foo<T> {
a: T,
}
struct Bar;
impl<T> Maker<Foo<T>> for Bar
where T: Default
{
fn make(&mut self) -> Foo<T> {
Foo {
a: <T as Default>::default(),
}
}
} |
Thank you very much for the clarification - it seems rather obvious now ! |
nham
pushed a commit
to nham/rust
that referenced
this issue
May 23, 2016
The previous explanation does not seem to explain what it means for an implementation parameter to be used or unused. The new explanation lists the three ways specific ways by which an impl parameter becomes constrained (taken from RFC 447). This also adds a link to RFC 447. The explanation has two different examples. The first is adapted from RFC 447, and shows an instance of E0207 on a impl for a type. The second one is a trait impl example adapted from issue rust-lang#22834. Closes rust-lang#33650
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
May 24, 2016
Improve the long explanation of E0207. The previous explanation does not seem to explain what it means for an implementation parameter to be used or unused. The new explanation lists the three ways specific ways by which an impl parameter becomes constrained (taken from RFC 447). This also adds a link to RFC 447. The explanation has two different examples. The first is adapted from RFC 447, and shows an instance of E0207 on a impl for a type. The second one is a trait impl example adapted from issue rust-lang#22834. Closes rust-lang#33650 cc rust-lang#32777 r? @GuillaumeGomez
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The code above fails to compile with error ...
... even though
T
is used in the associated typeFoo
. This example looks very similar to a legal case in the respective RFC, namely:One workaround is the use of
PhantomData
...... which to my mind shouldn't be required in the first place.
Meta
The text was updated successfully, but these errors were encountered: