> >> 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?