-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Error extending Fn trait then using it as a trait object: the value of the associated type `Output must be specified #24010
Comments
The problem is that the associated type is defined in a supertrait, and we don't consider that case when we check that the object type is well-formed. |
It can be quite painful to work around this problem, as it's the only way to create aliases for traits. When you have bounds such as the following scattered all over the code: |
@Diggsey: what workaround would you propose? I've been hitting my head against this wall for a while now, and am getting nowhere.. |
@jonhoo I don't know about your particular use-case, but for me I was using this to create a short alias for a trait - the workaround was just to use the long name everywhere, ie. |
My use-case is exactly the same. I was hoping I might be able to use a macro that expanded to the type, but that doesn't seem to work either. I suppose I'll just have to use the full signature for now.. |
@nikomatsakis Why is that case not considered? |
@Kimundi it's a bug, really. |
Ah, okay it sounded like that was intentional :) |
Is it going to be fixed in any upcoming version? |
This bug is very annoying. I have the same use case as @Diggsey and @jonhoo: creating an alias of a trait with cumbersome bounds that I don't want to have to repeat everywhere. In case it's not obvious from the title, this doesn't have to do with the trait A {
type Assoc;
// Pretend there are several more associated types here to make uses of `Box<A>` inconvenient.
}
trait B: A<Assoc=()> {}
fn takes_b(b: Box<B>) {} which results in:
The compiler should be able to infer that |
use std::iter::Iterator;
pub trait LeapfrogIterator<T, V> : Iterator<Item=(T,V)> {
fn next_above(&mut self, &T) -> Option<(T, V)>;
}
fn main () {
let v: Box<LeapfrogIterator<i64, i64>> = unimplemented!();
} is another concrete use case - if I want to extend |
I hit this when trying to create an alias of a FnMut trait. Using a macro still doesn't work as @jonhoo found two years ago, e.g. https://is.gd/h9CZ8H, because trait bounds don't seem to accept macro invocations. |
Also: * Avoid unhelpful compiler warnings * Capture common code in a macro Note: it would have been nice to alias the closure type, but rust-lang/rfcs#1733 is not yet implemented and macros can't cope (rust-lang/rust#24010).
Also: * Avoid unhelpful compiler warnings * Capture common code in a macro Note: it would have been nice to alias the closure type, but rust-lang/rfcs#1733 is not yet implemented and macros can't cope (rust-lang/rust#24010).
Also: * Avoid unhelpful compiler warnings * Capture common code in a macro Note: it would have been nice to alias the closure type, but rust-lang/rfcs#1733 is not yet implemented and macros can't cope (rust-lang/rust#24010).
Also: * Avoid unhelpful compiler warnings * Capture common code in a macro Note: it would have been nice to alias the closure type, but rust-lang/rfcs#1733 is not yet implemented and macros can't cope (rust-lang/rust#24010).
Also: * Avoid unhelpful compiler warnings * Capture common code in a macro Note: it would have been nice to alias the closure type, but rust-lang/rfcs#1733 is not yet implemented and macros can't cope (rust-lang/rust#24010).
Also: * Avoid unhelpful compiler warnings * Capture common code in a macro Note: it would have been nice to alias the closure type, but rust-lang/rfcs#1733 is not yet implemented and macros can't cope (rust-lang/rust#24010).
Also: * Avoid unhelpful compiler warnings * Capture common code in a macro Note: it would have been nice to alias the closure type, but rust-lang/rfcs#1733 is not yet implemented and macros can't cope (rust-lang/rust#24010).
Also: * Avoid unhelpful compiler warnings * Capture common code in a macro Note: it would have been nice to alias the closure type, but rust-lang/rfcs#1733 is not yet implemented and macros can't cope (rust-lang/rust#24010).
Also: * Avoid unhelpful compiler warnings * Capture common code in a macro Note: it would have been nice to alias the closure type, but rust-lang/rfcs#1733 is not yet implemented and macros can't cope (rust-lang/rust#24010).
Is it possible to give some mentoring hints for fixing this? |
Also: * Avoid unhelpful compiler warnings * Capture common code in a macro Note: it would have been nice to alias the closure type, but rust-lang/rfcs#1733 is not yet implemented and macros can't cope (rust-lang/rust#24010).
trait alias infrastructure This will be an implementation of trait aliases (RFC 1733, #41517). Progress so far: - [x] Feature gate - [x] Add to parser - [x] `where` clauses - [x] prohibit LHS type parameter bounds via AST validation #45047 (comment) - [x] Add to AST and HIR - [x] make a separate PathSource for trait alias contexts #45047 (comment) - [x] Stub out enough of typeck and resolve to just barely not ICE Postponed: - [ ] Actually implement the alias part - [ ] #21903 - [ ] #24010 I need some pointers on where to start with that last one. The test currently does this: ``` error[E0283]: type annotations required: cannot resolve `_: CD` --> src/test/run-pass/trait-alias.rs:34:16 | 34 | let both = foo(); | ^^^ | = note: required by `foo` ```
I think this is the same as #23856. |
@mbrubeck I think so too. Have we confirmed it yet? If so, worth closing this as duplicate. |
Okay, we have a fix! Waiting for review and merge on #55687. |
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
Output:
cc @nikomatsakis
The text was updated successfully, but these errors were encountered: