Skip to content
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

type ~std::iterator::Iterator<A>:Send does not implement any method in scope named map #8629

Closed
carl-eastlund opened this issue Aug 19, 2013 · 4 comments

Comments

@carl-eastlund
Copy link

Program:

fn imap<A,B>( i : ~Iterator<A>, f : &fn(A)->B ) { i.map(f) }
fn main () {}

Error:

iter.rs:1:50: 1:60 error: type `~std::iterator::Iterator<A>:Send` does not implement any method in scope named `map`
iter.rs:1 fn imap<A,B>( i : ~Iterator<A>, f : &fn(A)->B ) { i.map(f) }
                                                            ^~~~~~~~~~
error: aborting due to previous error
@bluss
Copy link
Member

bluss commented Aug 20, 2013

Iterator::map is not only a default method but it is called with self (by-value self), so it cannot be called here.

@carl-eastlund
Copy link
Author

Is there a different way to write this function that will work? Or is it impossible to abstract over an iterator and still use map?

@thestinger
Copy link
Contributor

You probably don't want to use trait objects, except in rare cases. You can use a generic function with an iterator:

fn foo<A: Iterator<int>>(xs: A) -> int {
    xs.map(|x| x * 2).fold(0, |a, b| a + b)
}

fn bar<A, B: Iterator<A>>(mut xs: B) -> bool {
    xs.len() != 0
}

@bluss
Copy link
Member

bluss commented Aug 20, 2013

(It should be possible to use .map with ~Iterator if the trait object is encapsulated in a wrapper struct that implements Iterator)

Jarcho pushed a commit to Jarcho/rust that referenced this issue Aug 29, 2022
Rework `only_used_in_recursion`

fixes rust-lang#8782
fixes rust-lang#8629
fixes rust-lang#8560
fixes rust-lang#8556

This is a complete rewrite of the lint. This loses some capabilities of the old implementation. Namely the ability to track through tuple and slice patterns, as well as the ability to trace through assignments.

The two reported bugs are fixed with this. One was caused by using the name of the method rather than resolving to the `DefId` of the called method. The second was cause by using the existence of a cycle in the dependency graph to determine whether the parameter was used in recursion even though there were other ways to create a cycle in the graph.

Implementation wise this switches from using a visitor to walking up the tree from every use of each parameter until it has been determined the parameter is used for something other than recursion. This is likely to perform better as it avoids walking the entire function a second time, and it is unlikely to walk up the HIR tree very much. Some cases would perform worse though.

cc `@buttercrab`

changelog: Scale back `only_used_in_recursion` to fix false positives
changelog: Move `only_used_in_recursion` back to `complexity`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants