Strided ranges could be a tertiary operator
similar to
x ? a : b
one could also parse
a .. b : c
as one entity.
About the efficiency issue, once again: for multi-dimensional arrays,
strides have less overhead than for one-dimensional arrays: All but one
dimension need run-time defined strides anyway.
On 03.11.2011 13:52, Christophe wrote:
bearophile , dans le message (digitalmars.D:146534), a écrit :
Robert Jacques:
[... several things]
Seventh, Matlab, NumPy, Octave, BLAS, etc. all support striding.
OK, a nice striding syntax for user defined types will be a good thing to have
in D2.
I have suggested the x..y:y syntax. Is this usable? Is this going to cause
problems?
Bye,
bearophile
: is already used for labels. If slice types are allowed, this can
cause trouble:
auto a = 0 .. 10; // a slice!(int, int) type.
a : 2; // is it a label or a stride ?
Of course, the example here is obvious, but maybe in real code this can
cause trouble.
stride(x..y, z) works just as good, and does not let people think it is
a very efficient langage builtin.
The langage just have to allow to define iota-like types with ..
Then a[x..y] becomes an opIndex() like Kenji suggested, and slices can
be used anywhere, like in :
multidimArray.columns(1..5);
