[Submission] D Slices

[eles]

> >> Basically, using subtraction in loop conditions is a big no-no.

then... why the compiler allows it? design should eliminate those
"big no-no"s. else, we tend again to "educate users", see the case
for not allowing writing:

while(condition);

and requiring instead

while(condition){}

just because the first was... well, a big no-no (at least from the
maintenance point of view).

next on the list, why not give access to the current index in
"foreach" instruction? while I find nice to write "foreach" as a
simpler way to loop through a collection, sometimes you need to do
some processing function of element's index. yes, there are some
issues for unordered collections (if any) and this could also prevent
some compiler optimizations, maybe.

D:

foreach(item; set) {
  // do something to item
}

Go:

for index, value := range someCollection {
  // do something to index and value
}

==or==

for index := range someCollection {
  // do something to index
}

Go seems to consider index information to be priority over the value
of the item. While this is debatable, I think it should be well to
provide the index information too in foreach loops. Maybe with a
slightly different syntax, such as:

foreach(index; item; set) {
  // do something to item
}

what do you think?