== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article > This is how I got to terms with it long ago: http://i.imgur.com/ lSkvs.png > When it's a slice, it's basically two anchors or gaps at some > location, and whatever items are between the anchors is your result. > Otherwise with indexing it's the number that starts at that offset (in > this case it would be at the location at right from the gap).
Nice picture, but then why foo[1] is rather 8 than 4? And what is foo [9]? For me is a bit cumbersome to put anchors "in-between", while still writing foo[1]. Yes, it defends a statu-quo, but what if the whole choice is wrong? Maybe we should write foo[1.5]. I am not (or, at least, I am trying to not be) a Matlab defender, but in slicing is like a... state of the art. Octave, Scilab are copying it. Why to reinvent the wheel? Occam's razor: complex explanations (like the anchor in the pictures) are required to explain unnatural choices. What if someone needs a model for ]-Inf,3] (ie. left limit is open)? He will still have to use the right-limit is open convention? The same for ]-2,0]. Rather, interpreting the slicing as a[start_position..slice_length] is more appealing (including for empty arrays) than the whole anchor concept. We could have then a[1..0] to represent empty array, and a[0..$] to represent the entire array. However, in that case a[1..1] would be a slice of just one element, containing a[1]. The bottom line is that I maintain my pov that a [closed_limit...open_limit] is a wrong choice. I fail to see any good example in its good favor and I know no other successful language (well, besides D) that uses this convention. Nor the reasons why it would do so.