Proposal: Multidimensional opSlice solution

[Don]

Norbert Nemec wrote:
> Don wrote:
>> Norbert Nemec wrote:
>>> Hi there,
>>>
>>> in implementing multi-dimensional arrays, the current way of 
>>> overloading the slicing operator does not scale up.
>>>
>>> Currently, there is opIndex working for an arbitrary number of 
>>> indices, but opSlice works only for one dimension. Ultimately, it 
>>> should be possible to allow slicing for more than one dimension, and 
>>> mixing it with indexing for e.g.:
>>>     A[4,7..8,7,2..5]
>>> So far, no clean solution for overloading this has been suggested.
>>
>> A solution was suggested while you were away.
>> You don't need a new opRange operator, a simple tuple struct like:
>> struct Slice(T) { T from; T to; }
>> in std.object is enough.
>> Note that:
>> A[4, Slice(7,8), 7, Slice(2,5)]
>>
>> will work with the existing compiler. So it's just a tiny syntax sugar 
>> issue.
> 
> I know this solution. It is exactly the "syntax sugar" issue that I see 
> as the problem here:
> 
> The compiler would need to be aware of the data type Slice. It would 
> therefore have to be something like a "builtin" type. If I am not 
> mistaken, the language definition so far never makes use of "builtin" 
> struct types.

You are mistaken <g>.
object, TypeInfo, AssociativeArray, ...
Complex will be added to that list, too.


>> And another simple possibility is to turn 7..8 into int[2][7,8].
> 
> That solution would unnecessarily get in to way of implementing indexing 
> by an array of indices:
> 
>     auto A = MyArray(["zero","one","two","three"]);
>     assert( A[ [2,3,0] ] == MyArray(["two","three","zero"]) );

But that syntax doesn't allow slices.

It's only an issue if a dimension can be BOTH a slice T..T, AND T[2], 
and they are not equivalent.
I tried to come up with a plausible scenario where it was really a 
problem, but failed. It requires that both T and T[2] are valid indices 
for the same dimension, AND that slicing is supported.

But this is all a bit academic since it's not going to happen. Maybe if 
you'd been around a few months back, things would be different.

>> However, Andrei argued that slicing of multidimensional arrays is so 
>> rarely used that syntax sugar is not necessary. Thus, it's not in D2.
> 
> Outside of numerics, multidimensional arrays are indeed rarely used. In 
> numerical programming, however, they are an essential ingredient. My 
> ultimate goal is to multidimensional arrays in D as comfortable as in 
> Fortran, Matlab or Python/NumPy in order to make D a real competitor in 
> that market.

Agreed. Multidimensional slicing is a costly operation, though, so I 
think the absence of syntax sugar is tolerable.
I see syntax sugar for slicing as much less important than 
multidimensional $, where the alternative is really quite ugly. So I 
pushed hard for opDollar.