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
