d-programming-language.org

[Daniel Gibson]

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