Can we fix reverse operator overloading (opSub_r et. al.)?

[Don]

Bill Baxter wrote:
> On Fri, Jul 10, 2009 at 8:15 AM, Andrei
> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>> Don wrote:
>>> The other thing that's desperately missing from D is multi-dimensional
>>> indexing.
>> What are the limitations of multiple-argument []?
>>
>> Andrei
>>
> 
> I don't know what Don had in mind, but multi-dimensional slice is
> ugly.  should be A[ a..b, c..d, e..f ] but currently you have to do
> something like A[ [a,c,e]..[b,d,f] ].   Or A[a..b][c..d][e..f] and
> bend over backwards to avoid creating too many temporary proxy
> objects. 

And I don't think the latter option is necessarily correct. If A is an 
array type, A[a..b][c..d] currently means assert(d-c <= b-a), 
A[a+c..a+(d-c)], with $=b while evaluating d and c.

  Also you'd like to be able to mix and match slices and
> indices like  A[ a..b, 3, e..f ].

This one, in particular, is what I had in mind.

> Also a basic built in multi-dim array would be nice.  I think most of
> the time when people make a new T(10,20) they don't really want 10
> arrays of length 20, each of which can be individually resized (and
> must be if more capacity is needed).   They want one array with size
> 10 x 20.

It's a bit trickier to provide that (other than just providing an 
operator-overloaded opIndex) since you'd then need to limit slicing on 
it, or else provide strided slices as a built-in type, as well.
Maybe that's better as a library type. Dunno.

Definitely we need a more powerful opIndex().