On 7/3/11 1:40 PM, eles wrote:
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.
Recently we have tightened the semantics of switch to reject "case
leak". Perhaps that should be reflected in the FAQ. Did you have other
change in mind? Why would the topic be flame-inducing?
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).
That's not a post-rationalization. It's exactly the reason of the choice.
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?
No, and it's not worth rehashing again the merits and demerits of
various arguments. Please don't bring this up again. Thank you.
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.
Safe on top of flexible is the best design. If there is anything
preventing you from defining a type with the behavior you mention, you
may want to file a bug.
Thanks,
Andrei
