Could there be IndexByCopy?

kornel · 2019-01-21T14:20:29.673Z

In the user forum there was a question about implementing Index on a wrapper of Vec<Cell<f32>>, and it turns out it’s not possible, because Index wants to return &T, and the Cell can’t allow that.

However, for Copy types like f32 returning a copy makes perfect sense. Would it be possible to add an indexing trait to the language that returns copies?

matklad · 2019-01-21T14:33:44.301Z

I think this is sort of blocked on generic associated types, which would allow an Index trait whose Output is parametreizes by a lifetime, so that you can return arbitrary reference or an ownded value

type Output<‘a>;
fun index(&’a self) -> Self::Output<‘a>;

sfackler · 2019-01-21T16:46:09.003Z

There was a closed RFC for IndexGet a couple of years ago that probably has relevant discussion: https://github.com/rust-lang/rfcs/pull/159

cuviper · 2019-01-21T16:58:06.007Z

You’d still need some kind of proxy type to implement IndexMut, but at least with GAT it could be something like RefMut<'a, T>. If nothing else, this indicates that such Index and IndexMut traits need to allow distinct Output types.

drXor · 2019-01-22T16:08:21.236Z

Wouldn’t the “right” solution be something like IndexMove that goes &move self -> &move Output? Of course, that requires solving outstanding problems with &move…

Yato · 2019-01-22T19:31:51.944Z

That would still require a lifetime and GATs because it is a reference.

drXor · 2019-01-22T20:56:44.190Z

I mean, yes, lifetime elision adds a lifetime to the signature. I don’t see why you need a GAT for for IndexMove.

Mind, I totally misread the OP, and IndexMove is the Wrong Thing. The thing that worries me about an Index-like trait that spits out copies is that &xs[n] is xs.index(n) right now, and in the situation in which you have e.g. IndexCopy, it is not clear if &xs[n] is a reference into xs or a reference to the immediate xs[n]. In this case, &xs[n] is absurd (since, notionally, it’s a reference into Cell), but it sounds to me like OP doesn’t want users to know about the Cells.

Phrased differently: I don’t think a type should have xs[n] (like Vec<impl Copy>, which simply copies out of the returned pointer) but not have &xs[n] (i.e., a notional pointer into xs which xs[n] can be copied out of).

Yato · 2019-01-22T21:29:10.883Z

Well, if we follow precedent, then &xs[n] is a reference to the immediate xs[n]. But as you said this is silly. I also think that adding an IndexMove or IndexCopy for this would be the Wrong Thing. I would use normal functions like index for this.

comex · 2019-01-23T07:06:14.299Z