Switch: Case Range Syntax

[Andrei Alexandrescu]

On 8/18/11 10:02 AM, Vijay Nayar wrote:
> On Wed, 17 Aug 2011 17:51:48 -0500, Andrei Alexandrescu wrote:
>
>>
>> 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
>
>  From this discussion, I gather that the 'switch' statement is effectively
> using '==' to compare to each 'case' statement value (I didn't know
> that's how it worked).
>
> Andrei, you are very good at explaining concepts in plain English, and I
> was hoping you could explain what D is seeing when it sees the 'case
> A: .. case B:' syntax.
>
> My current understanding is that 'switch' is effectively iterating
> through all it's top-level tokens, which are 'case', '..', and 'default',
> in a manner similar to a for-loop.  The special top-level token '..' is
> interpreted to effectively turn into new 'case' tokens starting from the
> last seen 'case' and ending when the next 'case' is seen.
>
> Is that correct?  Does the D 'switch' statement replace the '..' token
> with a bunch of 'case' tokens, thus allowing the 'swtich' hash-lookup to
> work quickly and efficiently?
>
>   - Vijay

The exact behavior is dependent on the compiler implementation. 
Essentially, yes, switch is recommended when you have branches of 
comparable probability, but don't read too much into specific 
implementation mechanisms, and don't mix language semantics with grammar 
minutia.

Andrei