if code like this worked: http://dpaste.dzfl.pl/7ea4eb03f02e

A few reasons why it doesn't:

You have to duplicate the case keyword when declaring case ranges. Why?

Case ranges are inclusive at both ends of the range, unlike in foreach. Again, why?

exponential notation (e.g. `2e9`) returns a double, not a long.


The exponential notation isn't really a problem, declaring some enums `enum i2e9 = cast(long)2e9;` deals with it fine. The case ranges are a wart though.

Solution:

Allow the second `case` keyword to be removed, which would then have the same semantics as the range in foreach.

E.g.
case 0 .. 4: // matches 0,1,2,3
case 0: .. case 4: // matches 0,1,2,3,4

No breakage, greater consistency, neater code, good stuff. At least as good as pascal.

Even better, the .. operator would become general (overloadable, too) and the case range would just be a special case of it.

On Tuesday, 14 October 2014 at 21:29:59 UTC, John Colvin wrote:
> You have to duplicate the case keyword when declaring case ranges. Why?
>
> Case ranges are inclusive at both ends of the range, unlike in foreach. Again, why?

It comes from writing:

switch(foo) {
  case 1:
  case 2:
  case 3:
  case 4:
     // code
}

Then just replacing the case 2 and case 3 with .. collapsing the repetition to just the beginning and the end. If you write it as:

switch(foo) {
  case 1:
  ..
  case 4:
     // code
}

vertically, that is, I think the rationale becomes a lot more clear. I like this a lot, it works brilliantly for me and makes good sense.

> Allow the second `case` keyword to be removed, which would then have the same semantics as the range in foreach.

That would be ok too.

On 10/14/14, 2:29 PM, John Colvin wrote:
> if code like this worked: http://dpaste.dzfl.pl/7ea4eb03f02e
>
> A few reasons why it doesn't:
>
> You have to duplicate the case keyword when declaring case ranges. Why?
>
> Case ranges are inclusive at both ends of the range, unlike in foreach.
> Again, why?
>
> exponential notation (e.g. `2e9`) returns a double, not a long.
>
>
> The exponential notation isn't really a problem, declaring some enums
> `enum i2e9 = cast(long)2e9;` deals with it fine. The case ranges are a
> wart though.
>
> Solution:
>
> Allow the second `case` keyword to be removed, which would then have the
> same semantics as the range in foreach.
>
> E.g.
> case 0 .. 4: // matches 0,1,2,3
> case 0: .. case 4: // matches 0,1,2,3,4
>
> No breakage, greater consistency, neater code, good stuff. At least as
> good as pascal.
>
> Even better, the .. operator would become general (overloadable, too)
> and the case range would just be a special case of it.

The short answer is it's all good as it is. -- Andrei

On Tuesday, 14 October 2014 at 21:33:36 UTC, Adam D. Ruppe wrote:
> On Tuesday, 14 October 2014 at 21:29:59 UTC, John Colvin wrote:
>> You have to duplicate the case keyword when declaring case ranges. Why?
>>
>> Case ranges are inclusive at both ends of the range, unlike in foreach. Again, why?
>
> It comes from writing:
>
> switch(foo) {
>   case 1:
>   case 2:
>   case 3:
>   case 4:
>      // code
> }
>
> Then just replacing the case 2 and case 3 with .. collapsing the repetition to just the beginning and the end. If you write it as:
>
> switch(foo) {
>   case 1:
>   ..
>   case 4:
>      // code
> }
>
> vertically, that is, I think the rationale becomes a lot more clear. I like this a lot, it works brilliantly for me and makes good sense.

Ah, yeah, that does make sense.

>> Allow the second `case` keyword to be removed, which would then have the same semantics as the range in foreach.
>
> That would be ok too.

On Tuesday, 14 October 2014 at 21:29:59 UTC, John Colvin wrote:
> if code like this worked: http://dpaste.dzfl.pl/7ea4eb03f02e
>
> A few reasons why it doesn't:
>
> You have to duplicate the case keyword when declaring case ranges. Why?
>
> Case ranges are inclusive at both ends of the range, unlike in foreach. Again, why?

Actually, the latter is the reason for the former. If incluseve ranges were defined (let's say with ...), then that becomes possible.