"Robert Jacques" <[email protected]> wrote: > On Mon, 10 Oct 2011 08:46:05 -0400, kennytm <[email protected]> wrote: >> Don <[email protected]> wrote: >>> On 10.10.2011 04:41, kenji hara wrote: >>>> 2011/10/10 bearophile<[email protected]>: >>>>> So is this: >>>>> y[$-6, 0..$:2] >>>>> >>>>> Translated like this? >>>>> y.opIndex(y.opDollar!0 - 6, y.opSlice!1(0, y.opDollar!1, 2)) >>>> >>>> I have no thought about it. >>>> I'm not sure that the additional stepping is really useful, but I >>>> think adding it into syntax is not impossible -- it might not conflict >>>> with associative array literal. >>>> >>>> Kenji Hara >>> >>> Personally, I think that since strided operations are so inefficient, >>> they should remain ugly. >> >> Slicing an nD static array is just as in/efficient as strides. That said, >> I'm still -1 on having a..b:c since (1) I see no practical need for strides >> and (2) even if we striding it doesn't need to be in the form a..b:c, e.g. >> arr[stride(0..$, 2)]. >> > > Regarding (1), from a computer vision/graphics perspective, being able to > only operate on the red channel, for example, is very nice. And I use > striding all the time in my CUDA code, but that's not as applicable in D, > yet. Striding tends to be most useful for working with packed data of some > kind.
Why not use a 'Color' struct?
