How to implement Index with interim view that owns an object

help
1

I have this code:

pub trait Index<'a, Idx>
where
    Self: 'a,
    Idx: ?Sized,
{
    type Output: ?Sized + 'a;

    fn index(self, index: Idx) -> Self::Output;
}

#[derive(Clone, Copy, Debug, Default, Eq, PartialEq)]
#[repr(transparent)]
struct Image(u32);

impl<'a> Index<'a, u8> for Image {
    type Output = Row<Self>;

    fn index(self, index: u8) -> Self::Output {
        Row { column: index * 9, inner: self }
    }
}

struct Row<T> {
    column: u8,
    inner: T
}

impl<'a> Index<'a, u8> for Row<Image> {
    type Output = u8;

    fn index(self, index: u8) -> Self::Output {
        1 & (self.inner.0 >> self.column + index) as u8
    }
}


fn main() {
    let img = Image(u32::MAX / 5);
    let element = img.index(0).index(0);
    // let element = img[0][0] // How?
    dbg!(element);
}

How can I rewrite this so that I can have the commented out line, by using the Index trait from the standard library? Is it even possible?

1 Like
2

Unless you store Rows in the Image (while making the whole structure non-self-referential) and hand out references to those, I don't see how you can satisfy the fact that Index::index returns &Self::Output not Self::Output.

1 Like
3

I thought as much, thank you. I guess it boils down tho this. It's a shame that the Index trait was not designed in a more flexible manner that allows returning owned values.

1 Like
4

AsRef and Borrow are other examples of traits that only allow you to hand out references to data already stored in the implementing type, not construct something new in the method body and return that.

5

Indeed, but this is less surprising, since the fact, that a reference is returned can be inferred from the name. And implementing a trait that is intended to return a reference (or a "borrow") to return an owned value would be nonsensical imo.
Otoh, imho returning a view or proxy object from an indexing operation is a valid use case.

6

I agree. My guess to why Index, AsRef and Borrow are designed the way they are is to avoid surprises on the user's side. I.e. I'd say the expectation of these operations is that they are cheap and there is no complex, potentially computationally expensive logic going on in them.

1 Like
7

It was designed for things like method chaining or modifying in place, which is why

    img[0]

notionally desugars to one of

//  v dereferences to a place expression
    *<Image as Deref>::index(&img, 0)
//  v dereferences to a place expression
    *<Image as DerefMut>::index_mut(&mut img, 0)

which is incompatible with your trait. The context sensitivity is also why IndexMut<_> uses Index<_>'s associated type, ala Deref/DerefMut, so the type of the place expression is the same in both cases. They would probably also be plagued with inference problems if the output were a generic parameter and not an associated type.

IndexOwned<_> or such would probably require mutually exclusive traits or such to be viable with inference. Or perhaps a strict order of preference, but then implementing traits would be a breaking, semantic-altering change.[1]

GAT/non-reference versions of Borrow, AsRef, and AsMut are more tenable, since they're not "mutable context sensitive" operators nor auto-dereferencing place expressions. They might have been designed differently if Rust 1.0 had GATs.

But Deref/DerefMut/Index/IndexMut, less likely IMO, at least not without more language features we don't yet have today.

  1. OTOH this can already be the case given method resolution ↩ī¸Ž

4 Likes
8

If the requirement is not that strict, you can take a look at the approach nalgebra took.

Basically it is img[(0, 0)].

1 Like
9

That's a sensible workaround. However, I'd still need to construct the u8 from the inner u32, which is an owned value. Who will own it when I return the reference to it?
I might implement const ZERO: u8 = 0; const ONE: u8 = 1; ... up to u8::MAX and return references to those. But this seems a bit hacky.