Skip to content

type inference bug with take/drop from std::iterator #6967

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
thestinger opened this issue Jun 6, 2013 · 2 comments
Closed

type inference bug with take/drop from std::iterator #6967

thestinger opened this issue Jun 6, 2013 · 2 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-type-system Area: Type system

Comments

@thestinger
Copy link
Contributor

The following works (as does drop_while):

use std::iterator::*;

fn main() {
    let _xs = Counter::new(0, 1).take_while(|&x| x < 20).to_vec();
}

However, take and drop run into a type inference bug:

use std::iterator::*;

fn main() {
    let _xs = Counter::new(0, 1).take(20).to_vec();
}
bar.rs:4:14: 4:51 error: cannot determine a type for this bounded type parameter: unconstrained type
bar.rs:4     let _xs = Counter::new(0, 1).take(20).to_vec();
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The definitions of TakeIterator and TakeWhileIterator are similar, but TakeIterator is only parameterized by T (the type of the contained Iterator) while TakeWhileIterator also has an A parameter (the type of the yielded element).

It seems the type of the element A is unable to be inferred from T, where T is an Iterator<A>.

/// An iterator which only iterates over the first `n` iterations of `iter`.
pub struct TakeIterator<T> {
    priv iter: T,
    priv n: uint
}

impl<A, T: Iterator<A>> Iterator<A> for TakeIterator<T> {
    #[inline]
    fn next(&mut self) -> Option<A> {
        let next = self.iter.next();
        if self.n != 0 {
            self.n -= 1;
            next
        } else {
            None
        }
    }
}
@thestinger
Copy link
Contributor Author

#6968 is a working hack to avoid this issue, but we should fix the underlying cause.

@Aatch
Copy link
Contributor

Aatch commented Jun 23, 2013

I have also hit this problem, but in my case, I end up needing to use four dummy type parameters and still needed to provide a hint when called. This is not tenable as a usable API.

I'm going to nominate this. I'm not sure what for, I'm thinking well-covered as this limits how complex you can feasibly make your types (not very, it turns out).

msullivan added a commit to msullivan/rust that referenced this issue Jul 20, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 8, 2021
Don't lint `manual_map` in const functions

fixes: rust-lang#6967

changelog: Don't lint `manual_map` in const functions
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

2 participants