other languages (Ada, Matlab) have solved this issue by only having a single syntax (for inclusive) ranges and starting their indexing at 1. By no means do i support this, i like my zeros. But these languages have another feature that makes inclusive ranges actually usable.
In my opinion, that is a bias introduced by the fact that there is no
last_idx() function and only a
len() function. I find
0 ... vec.last_idx() much more intuitive than
0 .. vec.len() (I always get the feeling I'm running one over the length of the array).
Ok, back to objectivity:
I did a search for
[^\.]\.\.[^\.\}\]\)] in the rust repos and went through the first 25% of the results (skipping all tests and benchmarks which just had random numbers in there).
Places where inclusive and exclusive ranges would result in the same effort (and subjective readability)
libcollections\ring_buf.rs:561 -> just a matter of how head/tail are used
libcollections\ring_buf.rs:584 -> just a matter of how head/tail are used
libcollections\str.rs:147 -> change iteration together with line 149
Places where inclusive ranges would be better
libcollections\ring_buf.rs:486 -> write as 1..len
Places where exclusive ranges are better
libcollections\string.rs:175, 192 -> that function could be prettier
libcore\fmt\mod.rs:599 -> better would be repeat
libcore\fmt\mod.rs:605 -> better would be repeat
Why would you ever do
&x[..0]? I'm sure there's a better way to create an empty slice with the proper lifetime (isn't there sth like
So... overwhelming number of situations where exclusive slices are "better" (in the current way stuff is done idiomatically in rust). Most of these situations are
x .. v.len().
My suggestion stands: stop using the length of anything to get an index, and instead have a function returning the index of the last item in a sequence. Then inclusive ranges can replace a lot of exclusive ones.