(ab)using ".." ranges, rectangular ranges?


So, I can acheive what I want with named functions: but I thought it would be nice to be able to use the range ‘operator’ to pair coordinates to represent a rectangular/cuboid etc region, for multi-dimensional arrays e.g. my3darray[min..max] // a 3d cuboid slice imagine being able to instigate block copies etc like that.

if I’ve understood right, the protocol quite allow it (because to actually iterate, it’s going to actually step the ‘start’ value… it’s expecting ‘T’ to support partial ord etc… “…” is more like a constructor for a simple struct than an ‘operator’ returning an iterator as such ?)

I realise first off there’s ambiguity… do you mean a line or an axial region: however, seeing it in array syntax I’d claim it suits an ND region

I suppose there’s the contrasting idea of having a Vec3<Range<i32>> eg Vec3(min.x…max.x, min.y…max.y, min.z…max.z) but as you can guess what appealed to me was being able refer to it concisely etc

is this idea just stretching the syntax too far, or has anyone else wanted to do this… are there options i’ve missed.

the appeal of the operator over named functions is there’s naming to (dis)agree on … it’s very guessable once you’ve seen it on the primitives

I know rust also has tuples which can make using pairs easy, they’re an ok option too


x[a..b] is a standard Rust syntax, so it might be surprising if it does something clever. Maybe use x[(a, b)] to make it clearer it’s overloaded?


is a standard Rust syntax,

that’s kind of why I want to use it this way: it makes a lot of sense to me that it would generalise to more dimensions. (One thing that’s nice in C++ is how they’ve extended the number of ways in which you can use ‘standard syntax’ e.g. initialiser lists with custom types, but rust is an opportunity in that it’s ‘standard syntax’ is fresher; a…b is really nice to have)

of course at this point it’s academic . One sticking point is that Index,IndexMut demand returning &T , with T specified… I can’t return an intermediate accessor structure (so i can’t write dest_image[rectmin..rectmax] = src_image[rectmin..rectmax] or whatever)

I’ve not tried , but do the ‘maths languages’ generalise their multidimensional array support this way (I know they might use : instead of .. for ranges, but once you get the right range symbol the intuition would be the same)


Typically, math languages rather do something like my_voxels[xi…xf, yi…yf, zi…zf], which in Rust you could probably approximate with a tuple of ranges.


The traits returning references require that whatever you return already exists in the source object, so you’re limited to only: a field of a struct, an element of some slice, or a contiguous slice. All must be pre-existing and accessible from the self object. If you’d need to create any new object for a header or a tuple to return two or more slices, you’re out of luck - these require an owned return type. There’s a feature request for Rust to support “custom DST” that would remove this restriction.