[Submission] D Slices

[eles]

== Quote from Andrej Mitrovic (andrej.mitrovich at 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.