Add .nth() method to Slice type

[jturner314]

This PR adds an nth() method for the Slice type.

Instead of adding an nth() method, it would be possible to implement IntoIterator for Slice and specialize nth(), but I think it's useful to provide nth() on Slice itself. It would be nice to implement Index for Slice instead of nth(), but I don't think that's possible because Index::index() must return a reference.

I was planning to include a len() method as part of this PR, but after thinking about it some more, I don't see a good use-case for len().

If you don't think the nth() method is sufficiently useful to include in ndarray, that's fine too. I just found it useful in my own code and thought I'd propose it.

[bluss]

What meaning do we give to a step of 0? It used to be an error when using it for slicing, I'll have to check again.

[jturner314]

If you actually call slice() with a step of 0, then you'll get a panic. (See dimension::do_slice.) You'll also get a panic when calling slice() if the slice begin/end is out-of-range.

In contrast, nth() doesn't panic in these cases. It's possible to change it to panic if step == 0, without changing the function signature. To make it panic for out-of-range indices, it would need an argument for the length of the axis you're going to slice.

If you'd prefer it panic in those cases, I'd probably choose a different name (e.g. index()) instead of nth().

[bluss]

Great, thanks for clarifying!

That sounds you have no particular behaviour in mind for 0, so we can choose one freely. I'm not too fond of mixing panics in explicitly checked or fallible methods either, so I'm not sure. I do lean towards that it should be a panic -- maybe a debug assertion. Maybe indeed a debug assertion already in Slice::new ? Or is that redundant?

[bluss]

Ah with public fields a debug assertion in new doesn't do much good anyway.

[jturner314]

It's certainly possible to make the fields non-public (or maybe just step) and add an assertion to new() and step_by(). In some ways, I think that's a better design anyway; what do you think? It's still not possible to handle out-of-range indices this way, but it would catch step == 0 early.

If we make some of the fields in Slice non-public, I would also change enum SliceOrIndex { Slice { start, end, step }, ... } to enum SliceOrIndex { Slice(Slice), ... } to hide the fields there too.

Edit: If it matters, Python's slice type does allow step == 0.

[jturner314]

I just realized that the implementation of nth() in this PR doesn't match the current slicing behavior for negative steps, so please don't merge it yet. (I incorrectly assumed that the current behavior matched Python.) I'll fix this PR based on the outcome of the discussion in #312.

[jturner314]

As I mentioned on IRC, I realized that it's not possible to correctly handle negative start/end indices without taking the length of the axis as an argument, which makes nth() not very useful. So, I'm closing this PR.