Proposal: Make [][x] and [][a..b] illegal (reserve for multidimensional

[Dan]

Bill Baxter Wrote:

> Don Clugston wrote:> 
> Another proposal would be to allow [..] as your slice an move on syntax, 
> and keep the current meaning of [].

Jeepers, we already have $ as a shorthand for length.  Is 0..$ really too long?  Even an 11 dimensional array is legible with that.  11 dimensions is barely comprehensible to even the best mind.  Most folk can't even perceive 4.

x[0..$][0..$][0..$][0..$][0..$][0..$][0..$][0..$][0..$][0..$][0..$];

> Also one thing not clear to me with your proposal is whether 
> f[1..2][2..3][3..4] generates 3 opSlice calls or just 1 when applied to 
> a user class.  I can see reasons for wanting both.  If you have a fixed 
> dimension class that only allows integer slicing, then probably 1 
> opSlice call with all 3 slices is the most useful.  If you have 
> something representing a N-dimensional thing where N is runtime, and you 
> allow for slicing with objects (like other N-dimsional arrays), then 3 
> separate chained calls like f.opSlice(a).opSlice(b).opSlice(c) might be 
> more useful to cut down on all the combinatorial explosion of possible 
> combos of opSlice arguments.
> 
> --bb


Yeah, I tend to agree with using 3 separate opSlice calls.  But... we don't even need to create an opSlice method, do we?  Arrays already work wonderfully?  Doesn't:

[code]
float[42][12][14] x;
float[42][2][2] y;

y = x[0..$][1..2][3..4];
[/code]
That works, right?  and you can loop over it just like this?
[code]
for(int i = 0; i < x.length; i++)
{
   for(int j = 0; j < x[i].length; j++)
   {
   }
}
[/code]

I don't see the problem?