Multidimensional slice

[Rafael]

On Wednesday, 19 December 2012 at 15:19:01 UTC, Nekroze wrote:
> On Wednesday, 19 December 2012 at 14:08:25 UTC, Rafael wrote:
>> On Wednesday, 19 December 2012 at 13:28:24 UTC, Nekroze wrote:
>>> On Wednesday, 19 December 2012 at 12:27:32 UTC, Rafael wrote:
>>>> 1) It is possible to implement multiindex access using 
>>>> opIndex* methods, moreover this is the simplest way to 
>>>> multiindex access realization. So, we have [i, j, k] 
>>>> notation. Next step after it - slices implementation and it 
>>>> looks logical to save the same notation for it: [i1..i2, 
>>>> j1..j2, k]. But it impossible, if I understand correctly.
>>>>
>>>> 2) On the other hand. Syntax via [i][j] leads to some 
>>>> overhead: first index access [i] must return some light 
>>>> accessor object (like range (or iterator)) which supports 
>>>> the index access operation. But using this approach it is 
>>>> possible to implement multidimensional slices. And this 
>>>> means, that opIndex* methods with multiindex are not needed.
>>>
>>> Well if you are looking at operator overloading you can 
>>> overload opSlice as described here 
>>> http://dlang.org/operatoroverloading.html#Slice however i am 
>>> not sure if you can defined multiple slices delimited by 
>>> commas in the same [] block but it is worth a try.
>>
>> ...and we return to my initial question :)
>> The answer is: no, D is not support multidimension slices. 
>> Possible way to solve it is to define some auxiliary structure 
>> Slice, and use multiindex by following way:
>> S [ Slice(0, $), 2] = A [ Slice(0, $), 2];
>
> Instead of defining a struct for that why not allow index to 
> take a uint array defining the lower and upper bounds of the 
> slice. You may have to make the opSlice or opIndex a template 
> however but I believe you should be able to take a uint[2] as 
> an argument.
>
> Atleast this way you dont have to add more structs to the mix 
> and you can just do:
> S[[0, S.length], 2] = A [[0, A.length], 2];
> or some such, there may be a way of preserving the $ symbol but 
> you would have to deal with that anyway if you made it an 
> argument to a struct. perhaps a string mixin?

Yes, it is good solution, thank you! But anyway it means not so 
nice and laconic syntax..

P.S. yes, I am killjoy :)