On 2009-07-07 01:12:12 -0400, Andrei Alexandrescu
<[email protected]> said:
Nick Sabalausky wrote:
Those examples are all cases where the meaning and context are wildly
different fbetween one use and the other. But with '..', both uses are
very similar: "From xxx to (incl/excl) yyy". Big differences are ok,
they stand out as obvious. Small differences can be more problematic.
You'd have an uphill battle using a counterfeit Swiss army knife
against a battery of Gatling guns
arguing that
case 'a': .. case 'z':
is very similar with
0 .. 10
That's actually much more different than e.g.
a = b * c;
versus
b * c;
They aren't so much different if you consider "case 'a':" and "case
'z':" as two items joined by a "..", which I believe is the expected
way to read it. In the first case "case 'a':" and "case 'z':" joined by
a ".." means an inclusive range, in the second case "0" and "10" joined
by a ".." means an exclusive one.
With "b * c", the meaning is completly different depending on whether b
is a type or not. If "b" is a type, you can't reasonabily expect "b *
c" to do a multiplication and you'll get an error about it if that's
what you're trying to do. Wheras with "case 'a': .. case 'b':" you can
reasonably expect an exclusive range if you aren't too familiar with
the syntax (and that's a resonable expectation if you know about
ranges), and you won't get an error of you mix things up; thus, clarity
of the syntax becomes more important.
I still think that having that syntax is better than nothing, but I do
believe it's an inconsistency and that it may looks ambiguous to
someone unfamiliar with it.
But my worse grief about that new feature is the restriction about 256
values which is pretty limitating if you're writing a parser dealing
with ranges of unicode characters. I guess I'll have to continue using
ifs for that.
--
Michel Fortin
[email protected]
http://michelf.com/
