allow strided slice indexing: m[0, 0..5, _, R(0, $, 2), R($-1, 0, -2) ]

[timotheecour]

discussed here: https://docs.google.com/document/d/1cEf8AynZEZxlTENJx1i4w1GTB481bbc4iUbUeJT00-U/edit#heading=h.kv2inl5g6n2a

Also note that i..j only works within opIndex, not within opCall (math index), so R(i,j) is needed for opCall (and should also be allowed for opIndex for uniformity)

Also this syntax sugar (built on top of R) is convenient:

enum _=R();
R(...).reverse
inclusive(a,b,-2)

also discussed in the doc

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/30070920-allow-strided-slice-indexing-m-0-0-5-_-r-0-2-r-1-0-2?utm_campaign=plugin&utm_content=tracker%2F18251717&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F18251717&utm_medium=issues&utm_source=github).

[9il]

Syntax problem: $ does not work with math index order.

[timotheecour]

yes, neither does slice i..j.
[although this is slightly orthogonal to this issue, which deals with opIndex]

alternatives for defining a math order (instead of opCall):

m[a,b,c] //C order
m(c,b,a) //math order [but issues with i..j and $], which you just implemented
m.math[c,b,a] // via a math property 
m[math,c,b,a] // via a math extra arg

Yet another possibility is to extend language to support $, and i..j inside opCall.

any other idea?

Independently of these limitations on opCall, there was discussion at some point to also support i..j:stride to avoid R(i,j,stride) but I don't remember where that went.

[9il]

Syntax changes look good to me. One for i..j:stride, and another to make opCall like opIndex.
There is wiki page for DIPs http://wiki.dlang.org/DIPs

[9il]

wontfix in near future