Matrix-type-friendly syntax and more

[Norbert Nemec]

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);