Am 03.07.2011 20:40, schrieb eles: > > 2. http://www.d-programming-language.org/faq.html#case_range (Why > doesn't the case range statement use the case X..Y: syntax?) > > saying that "Case (1) has a VERY DIFFERENT meaning from (2) and (3). > (1) is inclusive of Y, and (2) and (3) are exclusive of Y. Having a > very different meaning means it should have a distinctly different > syntax." is a POST-rationalization (and, personally speaking, a real > shame for such a nice language as D) of a bad choice that was > exclusive-right limit in x..y syntax. Just imagine that you could > allow "case X..Y" syntax and avoid that explanation (and faq). > > I made several arguments for changing this syntax: > -logic (not just code-writing or compile-writing easiness) consistency > -consistent representation on the same number of bits of the maximum > index of an array (while the length is not representable) > -the fact that multi-dimensional slicing (possibly, a future feature) > is far more convenient when x..y is inclusive (just imagine > remembering which those elements are left out on those many- > dimensions of the data) > -the fact that Ruby has implemented the inclusive syntax too (so > there was some need to do that although the right-exclusive syntax > was already available) > -disjoint array slices would have disjoint index ranges (imagine > cases where consecutive slices overlap a bit, like in moving average > applications) > -now, the fact that "case X..Y" syntax will be allowable > > I know that is implemented that way (and vala and python went with > it). What would be the cost to replace those X..Y with X..(Y-1)? > Aren't the above reasons worthy to consider such a change? >
Not this again, this (right border is exclusive) was already discussed at length. With you, actually. So why do you bring up this up again? Just accept that D handles ranges, slices, ... this way, it's not going to change anyway. Cheers, - Daniel