d-programming-language.org

[Andrei Alexandrescu]

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