1. please update http://www.d-programming-language.org/faq.html#q6 ("Why fall through on switch statements?").
"The reason D doesn't change this is for the same reason that integral promotion rules and operator precedence rules were kept the same - to make code that looks the same as in C operate the same. If it had subtly different semantics, it will cause frustratingly subtle bugs." was a good reason at its time, it is no more (since code is simply *not* accepted). now, flames are on (again) - well, I have no alternative. 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? Well, (almost) enough for now. I also maintain that unsigned types should throw out-of-range exceptions (in debug mode, so that release will run as fast as it gets) when decremented below zero, unless specifically marked as *circular* (i.e. intended behavior) or something like this. This will prevent some bugs. I see those quite often in my student's homeworks.
