I'm not overly enthusiastic about replacing one flawed system with another that also is flawed, but in different ways.
But this is not a question of replacing a system, but to add other system, isn't it?
/ Hedda (Vad ska jag äta idag då?)
Previous text:
2003-05-15 21:59: Subject: Negative ranges revisited
No, it's not the same as my suggestion. I had a "[-" part too, which is independent of the "..-" part. Each one would select indexing in either the 0..sizeof(x)-1 interval or -sizeof(x)..1 but never both at the same time. I.e. the fencepost cases in x[..i-1]+x[i+1..] would still work as today.
It'd work to adopt python-style ranges. If we do it I think we should deprecate the syntax with ".." since it'd be ugly with two different syntaxes and semantics for this.
However, python slices have their problems too:
One is the x[:-0] case. Although I generally like the a <= x < b style ranges, that special case is bad. I think it's about as bad as our current problem with negative ranges.
The other is the fencepost case that Pike currently handles more conveniently.
I'm not overly enthusiastic about replacing one flawed system with another that also is flawed, but in different ways. A solution that would really work is to abandon the notion of negative indices and instead add a proper count-from-the-end operator. Granted, that operator should not be the same as unary negation.
/ Martin Stjernholm, Roxen IS