Robert Jacques wrote:
On Tue, 17 Nov 2009 01:44:30 -0500, yigal chripun <yigal...@gmail.com> 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.

what tuple struct are you talking about?
we are discussing real true tuples that are supported by the language type system (meaning at compile-time), not some library struct type.

let me rephrase my sentence regarding slicing:
struct R { int start, stride, end; }
arrays should accept a list of the above R and a Dictionary should *not* implement slicing since that requires an order which dictionaries have no business to require.
OrderedDictionary!(T) (if you really want such a beast) would accept:
struct RR(T) {
T start, end;
int stride;
}

R and RR above are simplistic, real world impl. should make stride optional but the main point is that it is by no means a tuple.

I see what you're saying about two birds with one stone but from my POV instead of replacing old cruft with a useful and friendly to use new feature you just added more cruft and hacks to poorly support said feature with unfriendly and confusing syntax.

Reply via email to