d-programming-language.org

[eles]

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.