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.
