Bill Baxter wrote:
On Fri, Jul 10, 2009 at 8:15 AM, Andrei
Alexandrescu<seewebsiteforem...@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().
