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

a[b], the sugary version of *a.index(&b), seems to require type inference hints? #15734

Closed
japaric opened this issue Jul 17, 2014 · 2 comments · Fixed by #18555
Closed

a[b], the sugary version of *a.index(&b), seems to require type inference hints? #15734

japaric opened this issue Jul 17, 2014 · 2 comments · Fixed by #18555
Labels
A-type-system Area: Type system E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@japaric
Copy link
Member

japaric commented Jul 17, 2014

STR

// Sorry for the long example, didn't have time to make it shorter!
struct Mat<T> {
    data: Vec<T>,
    shape: (uint, uint),
}

impl<T> Mat<T> {
    fn new(data: Vec<T>, shape@(nrows, ncols): (uint, uint)) -> Mat<T> {
        assert!(data.len() == nrows * ncols);

        Mat {
            data: data,
            shape: shape,
        }
    }

    fn row<'a>(&'a self, row: uint) -> Row<&'a Mat<T>> {
        let (nrows, _) = self.shape;

        assert!(row < nrows);

        Row {
            mat: self,
            row: row,
        }
    }
}

impl<T> Index<(uint, uint), T> for Mat<T> {
    fn index<'a>(&'a self, &(row, col): &(uint, uint)) -> &'a T {
        let (nrows, ncols) = self.shape;

        assert!(row < nrows, col < ncols);

        &self.data[row * ncols + col]
    }
}

impl<'a, T> Index<(uint, uint), T> for &'a Mat<T> {
    fn index<'b>(&'b self, index: &(uint, uint)) -> &'b T {
        (*self).index(index)
    }
}

struct Row<M> {
    mat: M,
    row: uint,
}

impl<T, M: Index<(uint, uint), T>> Index<uint, T> for Row<M> {
    fn index<'a>(&'a self, col: &uint) -> &'a T {
        &self.mat[(self.row, *col)]
    }
}

fn main() {
    let m = Mat::new(vec!(1u, 2, 3, 4, 5, 6), (2, 3));
    let r = m.row(1);

    // GOOD
    println!("{}", r.index(&2) == &6);

    // BAD the sugary version doesn't work
    println!("{}", r[2] == 6);

    // BAD type annotating the index/rhs doesn't help...
    println!("{}", r[2u] == 6u);

    // GOOD it works OK in reverse...
    println!("{}", 6 == r[2]);

    // BAD indirection has no positive effect
    let e = r[2];
    println!("{}", e == 6);

    // GOOD unless it's type annotated
    let e: uint = r[2];
    println!("{}", e == 6);
}

All the lines marked with BAD yield these errors:

r[2] == 6: cannot determine a type for this bounded type parameter: unconstrained type
r[2u] == 6u: the type of this value must be known in this context
e == 6: the type of this value must be known in this context

Version

$ rustc --version
rustc 0.12.0-pre (459ffc2adc74f5e8b64a76f5670edb419b9f65da 2014-07-17 01:16:19 +0000)
@japaric japaric changed the title a[b], the sugary version of *a.index(&b), seems to require type inference? a[b], the sugary version of *a.index(&b), seems to require type inference hints? Jul 17, 2014
@alexcrichton
Copy link
Member

cc @pcwalton, this looks suspicious

@pnkfelix
Copy link
Member

cc me

@ghost ghost added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Oct 30, 2014
lnicola pushed a commit to lnicola/rust that referenced this issue Jan 3, 2024
…l-inside-types, r=Veykril

fix: no code action 'introduce_named_generic' for impl inside types

Fix rust-lang#15734.

### Changes Made
- Find params in `ancestors` instead of just `parent`
- Added tests (`replace_impl_with_mut` and `replace_impl_inside`)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants