split Index into Index, IndexMut and IndexAssign

[thestinger]

The current Index isn't great because you have to use &self and return &T or T (via clone) for a map/vector type.

I think it would be best to split it into Index (with &self), IndexMut (with &mut self) and IndexAssign (&mut self, inserting a value).

I'm unsure about the syntax. It would be nice to make it uniform with vector syntax and have &a["foo"] call Index for &T, etc.

[graydon]

Relative of #5992 -- dupe?

[thestinger]

@graydon: not quite, that's more about adding in-place versions of the binary operators with a mention of index-assign

[chris-morgan]

How about foo[bar] += baz? Where will that fit in (with regards to #5992; probably more appropriate there)?

[huonw]

@chris-morgan I imagine that would be handled by IndexMut i.e. "desugared" to something like foo.index_mut(bar).add_assign(&bar).

[bluss]

I'll mention the role of RandomAccessIterator (that is an experimental feature yet to find its proper formulation I think); RAI could be unified with the Index traits. However if traits like RandomAccess/RandomAccessMut are fleshed out, we will also see that the vec iterator and vec slice will start to look very similar.. (But, the random access traits are of course there to apply to much more than just vec iterators).

Edit: To give the traits purpose, for RandomAccess, think binary search, for RandomAccessMut, think generic sort.

[nikomatsakis]

cc me, I am working on overloading deref and so on, and this is related. I'll put in the specifics of my proposal in a bit.

[brson]

To move vec builders into the library we need overloadable index to be working correctly. Nominating.

[pnkfelix]

Accepted for 1.0, P-high.

[nikomatsakis]

To be concrete, I think it should work like this.

// self[element] -- if used as rvalue, implicitly a deref of the result
trait Index<E,R> {
    fn index<'a>(&'a self, element: &E) -> &'a R;
}

// &mut self[element] -- when used as a mutable lvalue
trait IndexMut<E,R> {
    fn index_mut<'a>(&'a mut self, element: &E) -> &'a mut R;
}

// self[element] = value
trait IndexSet<E,V> {
    fn index_set(&mut self, element: E, value: V);
}

These specifications make one crucial assumption: that the implementer can return a reference to the result. This is suitable for many if not all uses cases, but it disallows e.g. an implementer that was going to synthesize the result.

An alternative is to add a fourth trait, corresponding to self[element] used an rvalue:

// self[element] in an rvalue context
trait IndexGet<E,R> {
    fn index_get(&self, element: &E) -> R;
}

which would be intended for those cases where self[element] is used as an rvalue.

I am more-or-less indifferent as to which of these would be best.

[thestinger]

@nikomatsakis: I think it would be fine to reserve the syntax for in-memory data structures able to return a reference. As long as it's possible to implement what slices do today in a user-defined type, I'll be happy!

[wycats]

@nikomatsakis this looks fine as a starting point.

I think I want this as well:

// self[element] = value
trait IndexSetRef<E,V> {
    fn index_set(&mut self, element: &E, value: V);
}

I'm happy to pick up the work for your three traits and see how far I get.

[nikomatsakis]

I think it's plausible to have various set traits so long as a type implements at most one (or rather we try them in a specific order, so there's no point in implementing more than one)