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.
I think backwards compatibility is more important than making it not ugly though. I'm stil annoyed when pike warns me about writing 'string *', even though I don't really like that syntax. Deprecating *anything* is often a hassle for the end user.
At least in Pike we can use #pike to maintain backwards compatibility if we really do get rid of the .. syntax, when other languages change, they just become unusuable...
/ Fredrik (Naranek) Hubinette (Real Build Master)
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