Introduce remaining Index traits

[sfackler]

No description provided.

[lilyball]

👍 Overall I think this is good.

What happens if T implements Index and &T implements IndexGet? Seems like an ambiguity right there. And if the type T implements both Index and IndexGet then it seems like potential confusion. Could the compiler perhaps forbid both these scenarios? Plus the case of T implementing IndexMut and &mut T implementing IndexGet.

[sfackler]

Yeah, we'd probably want the compiler to forbid "overlapping" definitions.

[chris-morgan]

Why does IndexMut<E, R> require Index<E, R>?

[eddyb]

For the upgrade mechanism required to fix the DerefMut-in-immutable-contexts issue.
Or is it downgrade? In any case, one of IndexMut or Index is picked, and depending on whether the result is required to be a mutable lvalue (e.g. method call with &mut self) or not, the operation will be adjusted to use the more appropriate trait.

[SiegeLord]

Why can't IndexSet have a by-value self like IndexGet does? It seems like you already lost the generic usability once you define IndexGet like that, so why not make IndexSet just as flexible?

My use case is a matrix type defined like so:

struct Matrix<T>
{
    elems: Vec<Cell<T>>
}

[erickt]

I don't think we need IndexGet if we reformulate Index to keep the return type fully abstract:

extern crate collections;

use collections::Bitv;

trait MyIndex<'a, E, R> {
    fn my_index(&'a self, element: E) -> R;
}

impl<'a, T> MyIndex<'a, uint, &'a T> for &'a [T] {
    fn my_index(&'a self, element: uint) -> &'a T {
        &self[element]
    }
}

impl<'a> MyIndex<'a, uint, bool> for Bitv {
    fn my_index(&'a self, element: uint) -> bool {
        if self.get(element) {
            true
        } else {
            false
        }
    }
}

fn main() {
    let x = [1u, 2, 3];
    assert_eq!(x.my_index(0), &1u);
    assert_eq!(x.my_index(1), &2u);

    let mut x = Bitv::with_capacity(3, false);
    x.set(0, true);
    x.set(1, true);
    assert_eq!(x.my_index(0), true);
    assert_eq!(x.my_index(1), true);
    assert_eq!(x.my_index(2), false);
}

[sfackler]

I'm assuming the lifetime parameter in MyIndex is unneeded? It would also need to take self by value to handle the index-move case.

This option is mentioned briefly in the RFC. @alexcrichton had some concerns about it with respect to how the compiler would decide what &mut foo[i] and &foo[i] would desugar to. I think we can probably make it work with the right restrictions to prevent ambiguously overlapping implementations of Index (though I'm not totally sure what those would be).

I am still a bit concerned with the weirdness of the by-value overload setup, but it's not the end of the world, and it seems to add a lot more flexibility.

[erickt]

@sfackler: Ah, I apparently didn't understand that you meant in that section. I think if we go down my route, are there any situations where a data structure would want to have overlapping implementations of Index? The only one I can think of is for an optimization, as in: let v = vec!(1,2,3); let x = *v[1], but I bet llvm can already optimize that into an optimal form. If that's the case, I don't think it'd be that odd to have index return by-ref or by-value depending on the types. We already kind of do this with our iterators.

Also, the lifetime was needed, but with perhaps it's unnecessary now that we have lifetime elision?

[nikomatsakis]

This is an important topic, but by now it's clear we won't be getting to this at the moment. I hope we can come back to it shortly after 1.0 though. Postponing along with DerefMove under issue #997 (I see both issues as related and would like to address them together).