-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Incorrect "associated type must be specified" for trait objects #23856
Comments
Very strange. I'd expect the |
(comment copied from duplicate #36978 for locality purposes, since it contains a more-M WE) Consider the following: trait Foo { type FooT; }
trait Bar { }
trait FooBar: Foo<FooT=usize> + Bar { }
type BoxedFooBar = Box<FooBar>; Since the value of
To make it compile, one must duplicate the information at every use-site: trait Foo { type FooT; }
trait Bar { }
trait FooBar: Foo<FooT=usize> + Bar { }
type BoxedFooBar = Box<FooBar<FooT=usize>>; |
Am I looking at an example of this, or something else entirely? Playground example; that fails to compile with the same error as above in this thread. (Note that this example contains an error on my part: I intended to use the template parameter |
Yes, this is the same thing. |
Just ran into this today. As mentioned by @thanatos and in some linked duplicates, it appears to only impact trait objects. (if it impacted generic type parameters, I think there would be a lot more fuss over it!) trait MyFunc: FnMut() {}
impl<F:FnMut()> MyFunc for F {}
// OK
fn takes_generic<F: MyFunc>(mut f: F) { f(); }
// Error: missing associated type `Output` value
fn takes_trait_object(f: &mut MyFunc) { f(); }
fn main() {} Changing the trait object to a generic type parameter is a workaround in many, but not all, use cases. |
Just ran into this bug while trying to mix |
I ran into the same bug, in the same situation like @vorot93. |
I ran into that problem too, it's quite annoying. I hope a fix will pop soon. |
Any progress on this lately? |
Take supertraits into account when calculating associated types Fixes rust-lang#24010 and rust-lang#23856. Applies to trait aliases too. As a by-product, this PR also makes repeated bindings of the same associated item in the same definition a hard error. This was previously a warning with a note about it becoming a hard error in the future. See rust-lang#50589 for more info. I talked about this with @nikomatsakis recently, but only very superficially, so this shouldn't stop anyone from assigning it to themself to review and r+. N.B. The "WIP" commits represent imperfect attempts to solve the problem just for trait objects, but I've left them in for reference for the sake of whomever is reviewing this. CC @carllerche @theemathas @durka @mbrubeck
I think this issue has been resolved as of PR #55687, correct? The linked playgrounds no longer fail to compile, at least on a cursory inspection. Could we close this issue out? |
Looks fixed to me. |
The workaround for rust-lang/rust#23856 can now be removed.
Code:
Error:
playpen
I expect this code to compile without errors.
EDIT
This is the error on the current version:
Changing line 6 to
data: Box<MyIterator<Item=char> + 'static>,
moves the error to line 11:However, commenting line 11 and uncommenting line 13 makes the code compile fine.
The text was updated successfully, but these errors were encountered: