DMD 0.177 release [Length in slice expressions]

[Bill Baxter]

Reiner Pope wrote:
> Bill Baxter wrote:
>> Oskar Linde wrote:
>>> Bill Baxter wrote:
>>>> After trying to write a multi-dimensional array class, my opinion is 
>>>> that D slice support could use some upgrades overall.
>>>
>>> I'd be very interested in looking at what you've come up with. With 
>>> my own implementation of a multi-dimensional array type a couple of 
>>> months ago, I came to the same conclusion. I posted about it in:
>>>
>>> news://news.digitalmars.com:119/edrv0n$hth$1@digitaldaemon.com
>>> http://www.digitalmars.com/d/archives/digitalmars/D/announce/4717.html
>>>
>>>> What I'd like to see:
>>>>
>>>> --MultiRange Slice--
>>>> * A way to have multiple ranges in a slice, and a mix slice of and 
>>>> non-slice indices:
>>>>     A[i..j, k..m]
>>>>     A[i..j, p, k..m]
>>> (snip)
>>>  >      A[0..$,3..$]
>>>
>>> Yes, I would too. It is quite frustrating having the syntax in the 
>>> language but not being allowed to utilize it... :)
>>>
>>> I work around this by instead using a custom slice syntax instead:
>>>
>>> A[range(i,j), range(k,m)]
>>> A[range(i,j), p, range(k,m)]
>>> A[range(0,end), range(3..end)]
>>> A[end-1, p % end]
>>
>> Yeh, that's similar to what I'm doing too.  But it's pretty ugly.  So 
>> I guess that means you're using opIndex for everything and leaving 
>> opSlice alone.  Are you able to have ranges return arrays and specific 
>> indexes return scalar values that way?  That seems to me a big reason 
>> for having opSlice exist in the first place.  The .. in the brackets 
>> not only means you're slicing, it also means the function should 
>> return another array, versus returning an element.  That seems like a 
>> nice distinction to have to me.
>>
> Is there anything particularly wrong with having foo[a..b,c,d..$] being 
> syntactical sugar for foo[a..b][c][d..$] ? That way, I would imagine you 
> could implement slicing and indexing of multidimensional arrays quite 
> easily because, as Norbert Nemec said, indexing just returns an array 
> with dimension reduced by one, and slicing returns an array of the same 
> dimension, but perhaps different size. It also seems to allow any 
> combination of slicing and indexing without needing variadic functions.

Generally speaking, indexing isn't free.  And doing it three times is 3x 
more expensive than doing it once.  At the very least if the thing being 
indexed is a class then a new instance of that class has to be created 
for each index op.   But likely there's also some internal state that 
has to be copied and adjusted as well.  And one expects that indexing 
operations will often appear in inner loops, so they should be as fast 
as possible.

However, if you use some sort of proxy structs to represent the 
intermediate indexing expressions and only do the indexing when it's 
really needed, it may be ok to use [][][].  Basically it's expression 
templates all over again, just here the expressions are limited to 
indexing or slice operations.

That may work, and it may even be as efficient as a real multi-index 
slice with compiler optimizations, but I think it will result in code 
that's far less clear and probably not as fast.

If it does pan out, though, then there are certainly advantages as you 
say to only having to worry about two cases ever -- single index and 
slice index.  Not the any-possible-combination-of-index-and-slice, which 
admittedly requires some slick vararg template trickery itself.

Anyway, I plan to try implementing that soon (with all the brackets, 
naturally since the syntactic sugar you mention currently doesn't exist).

--bb