Operator overhaul

[Russell Lewis]

Bill Baxter wrote:
> (Reply to message on d.announce)
> 
> On Wed, Oct 22, 2008 at 9:36 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> Jason House wrote:
> 
>>>> Is there a good reason why it shouldn't be possible to use opAssign as
>>>> a replacement for opIndexAssign?
>>>>
>>>> --bb
>>> opindexAssign will still be needed when opindex has a non-ref return type.
>> I think the entire operator paraphernalia is due for a serious overhaul.
> 
> O_o!  Oh noohs!  We may have to start calling it the "E" language soon.
> 
> Seriously, though, if the overhaul makes it possible to do multiple
> slices with multiple $'s, then I'm all for it.
> As in   hyperArray[$-1,  1..$,  0..$-2]
> Even better would be python's "just leave it out" slicing:
> As in   hyperArray[$-1,  1..,  ..$-2]
> 
> It's a bit easier to read in my eyes.
> 
> There was also the stuff discussed before about passing in the op as a
> delegate or template parameter to give the class designer a chance to
> run some pre- or post- op code as desired.  Or rewriting x+=y type ops
> to be x=x+y
> 
> So we have:
> 1. multiple slice indexing
> 2. generalized $ indexing
> 3. generalized op execution
> 
> Any other operator-related issues?

While we're at it, we need to think about lazy slicing (with $).  Say 
that you have an lazy array type (where it only generates the members 
when required).  In that sort of situation, you don't necessarily want 
to generate the entire array (so that you can calculate the length) the 
first time that somebody does
	a = a[0..$-1];
or
	tmp = a[$-1];

You want to be able to keep a reference that says "so many characters 
from the end of the array, though the length of the array isn't known yet."