Consider alternative syntax for slicing (Index and IndexMut)?

[alexpyattaev]

Compared to Python, ndarray crate has an obvious difference in slicing. Arguably, this is the most annoying part of ndarray library. It would be nice to be able to do something like the following:

    let  a = SomeMatrix::default();
    let y = &a[1]);
    let x = &a[1..3]    
    let z=  &a[[1..3, 4..3]]);

Now with ndarray, this code would look quite nasty, but it does not have to. Rust does allow the Index operator (i.e., [])to be "overloaded" depending on the type of whatever is being used as "indexer", as in the example below:

#[derive(Default)]
struct ArrayBase{
    data:[u32;5]
}

impl  std::ops::Index<std::ops::Range<usize>> for ArrayBase
{        
    fn index(&self, index: std::ops::Range<usize>) ->  &Self::Output{
        &self.data[index]
    }
    type Output = [u32];
}

impl  std::ops::Index<usize> for ArrayBase
{        
    fn index(& self, index: usize) ->  &Self::Output{
        &self.data[index]
    }
    type Output = u32;
}

Using this, one could have the nice syntax actually work. Obviously, this extends to higher dimensions too:

impl <const D:usize>  std::ops::Index<[std::ops::Range<usize>;D]> for ArrayBase<D>
{        
    fn index(&self, index: [std::ops::Range<usize>;D]) ->  &Self::Output{
        todo!()
       // &self.data[index]
        
    }
    type Output = ArrayBase<D>;   
}

There are several "blindspots" here (such as inability to "collapse" dimensions when range is empty or contains only one element, or mix range and integer slicing), but the key question is whether the ndarray users find it useful/appropriate to make the necessary changes to the crate to enable this at all.

[bluss]

Moved to dicussion. This syntax and index trait is technically not feasible for ndarray - I've explored it years back. If things have changed, and new features enable it, that's great, just need a POC that shows how it works. We don't use slices, so the poc needs to use something that's sort of equivalent to array views.

I think ndarray is interested in this idea, but you'll need to show that it works 🙂. Some of us have explored it and found out why it didn't work at the time.

[bluss]

This RFC and its document describes the problem space as I know it. It mentions ndarray explicitly

rust-lang/rfcs#2967
https://github.com/oli-obk/rfcs/blob/procedural-vtables/text/0000-procedural-vtables.md#slicing-into-matrices-via-the-index-trait

[bluss]

And rust-lang/rfcs#2594 (comment)

[alexpyattaev]

We don't use slices, so the poc needs to use something that's sort of equivalent to array views.

Can you elaborate on this? Do you mean that the Index implementation should return ArrayView?

[bluss]

I'm giving you freedom to define anything that works, similar to ArrayView, doesn't have to be exactly array view. But it can't be a slice (a slice is 1D, and it is contiguous, both limitations we need to lift.) See other comment for more links.

[alexpyattaev]

Ok, I'll see if some dark magic can be applied to make this work for ArrayView. I have a nagging suspicion that the only way this can work is with macro grenerated impls for different dimensionalities. I'd much prefer to avoid this though as it slows down the compiler.

[bluss]

Whatever you find out, is useful. Note that the developers (me) have said that they think it's not possible in Rust's current feature set at all, but if you find something, it would be good to see.