Switch: Case Range Syntax

[Andrei Alexandrescu]

On 8/17/11 2:35 PM, Jacob Carlborg wrote:
> On 2011-08-17 19:48, Jonathan M Davis wrote:
>> On Wednesday, August 17, 2011 10:27 Vijay Nayar wrote:
>>> D adds a very handy feature that allows you to check for a range of
>>> values in a single case. Is there a particular reason that the syntax
>>> "case<start>: .. case<end>:" is used instead of treating the case
>>> statement similarly to an array slice, e.g. "case<start> ..<end>:"?
>>>
>>> For example:
>>>
>>> import std.stdio;
>>>
>>> void main() {
>>> int bob = 12;
>>> switch (bob) {
>>> // Why not "case 0 .. 9:"?
>>> case 0: .. case 9:
>>> writeln("Less than 10.");
>>> case 10: .. case 19:
>>> writeln("Less than 20.");
>>> case 20: .. case 29:
>>> writeln("Less than 30.");
>>> break;
>>> default:
>>> break;
>>> }
>>> // Output: Less than 20. Less than 30.
>>> }
>>
>> I don't know, but ranged case statements don't have the same semantics as
>> giving a range of values when slicing or to a foreach loop, so that
>> may be
>> why.
>>
>> arr[0 .. 10]
>>
>> does _not_ include the element at index 10.
>>
>> case 0: case 10:
>>
>> _does_ include 10. So, it actually probably be a bad thing for them to
>> use the
>> same syntax. To use the same syntax for both would make the semantics
>> of that
>> syntax inconsistent and confusing.
>>
>> - Jonathan M Davis
>
> D should have a built-in range type. One that supports syntax for both
> including and excluding the last element:
>
> auto a = 3 .. 5
> auto b = 3 ... 5
>
> Then we wouldn't need a special range syntax for switch statements. You
> could store ranges in variables and pass them to functions. opSlice
> probably wouldn't be needed, instead opIndex could be used and you would
> declare the method to take a range instead of two integers.

I doubt that would work well. Let's ignore for now mundane issues such 
as the ambiguity of 3...5 and focus on something like:

int x;
...
switch (x) {
case 3 ... 5: return 1;
default: return 0;
}

We'd need to change the behavior of switch anyway, or we'd need to 
define equality such that e.g. 4 == 3 ... 5. But then equality is not 
transitive anymore because 4 == 2 ... 6 too, but 3 ... 5 is not equal to 
2 ... 6.

Adding new built-in types is not easy. For a variety of reasons we 
should move the other way (per e.g. the hashtables discussion elsethread).


Andrei