Change representation of dynamic arrays?

[Janice Caron]

On 10/20/07, Bill Baxter <dnewsgroup at billbaxter.com> wrote:
> It becomes relevant if $ becomes a synonym for .length as was previously
> proposed.  In that case you don't get to decide how $ is implemented.
> It has to compute the length, even if that's O(N) and not really needed
> for computing the $-1'th node.
>
> Or if all you're trying to do is make a light wrapper around a built-in
> array (to, say, add an extra data member to it), then it means that your
> opIndex could be significantly less efficient than the built-in one.

I guess what I was thinking is... suppose I have an arbitrary,
user-defined collection class:

    MyCollection!(int) c;

and I want to dereference the last element. The source code might be:

    int n = c[$-1];

Now, currently, (or if $ gets defined as length), that would get turned into:

    int n = c.opIndex(c.length()-1);

which /might/ be computationally intensive, depending on what
MyCollection does with length() and opIndex(). The thing is, Walter
seemed to imply that iterators were on their way, so what I was
thinking was, if

    int n = c[$-1];

could instead be translated into

    int n = *(c.end()-1);

then the computational overhead would vanish. I think we'd need
something like opDereference() to overload the unary *. But, see,
you'd never actually have to /write/ the *, because you'd still write
"c[$-1]" - it's just what's going on under the hood.

Similarly, I'm thinking the expression c[a,$-b] could turn into
opRange(c.begin()+a, c.end()-b), instead of c.opIndex(a,
c.length()-1).

But it's all just pie in the sky right now, because I've got
absolutely no idea what, if anything, Walter plans to do with
collections and iterators.