"with" still sucks + removing features + adding features

[Jeremie Pelletier]

Derek Parnell Wrote:

> On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote:
> 
> > Bill Baxter wrote:
> > Although non-inclusive ranges are common enough that they deserve their
> > own syntax, I think inclusive ranges are *also* important enough to
> > deserve their own syntax.  Writing '+1' is often error-prone or even
> > just plain wrong (such as when it leads to integer overflow).
> 
> Agreed.
> 
> > I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
> > and similar to 'a .. b' without being too similar.  It does require the
> > programmer to pay attention, but that's unavoidable.  From there, it
> > naturally follows that 'case's in a 'switch' statement should follow the
> > same convention.
> 
> Sorry, but I don't share your sense of "easy to read" here. The eye can
> glaze over the third dot very easily and just not notice it.
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> skype: derek.j.parnell

I disagree, the ... syntax was also my suggestion for the reason that it is a very obvious syntax that isn't limited to only the switch ranges.

I don't think its that easy to miss a third dot, especially if there are spaces around the operator, and the editor uses a fixed-width font (like any good editor should).

If you want to be paranoid about confusion, comment it, just like closing }'s are often seen with a comment of the opening statement, just like you would do:
} // version(Windows)
you can do:
case 1 ... 10: // inclusive

You could also configure your editor to color code them differently, I already do that with a lot of other things, it gives the brain one more cue  to detect what is going on.

And since the operator also leaves .. available for inclusive ranges you can do:
case FIRST .. LAST + 1:

or even better:
enum CASE_LAST = LAST + 1:
case FIRST .. CASE_LAST:

This goes along with the best feature of D: let the programmers do things the way they want to.