On Tue, 17 Nov 2009 01:44:30 -0500, yigal chripun <[email protected]>
wrote:
Robert Jacques Wrote:
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b => tuple(a,b), since it also solves the
multi-dimensional slicing and mixed indexing and slicing problems.
what overhead? It's all in your imagination :)
a..b is confusing and bad UI. a..b means for humans the range of a till
b and not the tuple of the two.
if I see something like "hello"..42 I would assume the person who wrote
this was high on something.
multi dimentinal slicing should accept an integer range type and NOT a
tuple.
The unnecessary creation and setting of a tuple struct is by definition
overhead. Also, containers will have non-integer slices, e.g.
dictionary["hello".."world"], and strided ranges would even mix types:
"hello"..42.."world". My point isn't that '..' was a better syntax than
'(,)'. It's that '..' needs to change to something very much like a tuple
and therefore could be used to kill two birds with one stone.
