D2 Short list -- opSlice

[Steven Schveighoffer]

On Thu, 19 Nov 2009 08:09:14 -0500, Don <nospam at nospam.com> wrote:

> Steven Schveighoffer wrote:
>> On Thu, 19 Nov 2009 03:53:51 -0500, Don <nospam at nospam.com> wrote:
>>
>>> Andrei Alexandrescu wrote:
>>>> We're entering the finale of D2 and I want to keep a short list of  
>>>> things that must be done and integrated in the release. It is clearly  
>>>> understood by all of us that there are many things that could and  
>>>> probably should be done.
>>>>  1. Currently Walter and Don are diligently fixing the problems  
>>>> marked on the current manuscript.
>>>>  2. User-defined operators must be revamped.
>>>
>>> Should opIndex and opSlice be merged?
>>> This would be simpler, and would allow multi-dimensional slicing.
>>> Probably the simplest way to do this would be to use fixed length  
>>> arrays   of length 2 for slices.
>>> So, for example, if the indices are integers, then
>>> opIndex(int x) { } is the 1-D index, and
>>> opIndex(int[2] x) {} is a slice from x[0] to x[1],
>>> which exactly corresponding to the current opSlice(x[0]..x[1]).
>>  I hope you still mean to allow arguments other than int.
>
> Read it.
> "So, _for example_, if the indices are integers,".

D'oh, sorry for the noise :(

>> Also, how does this work with Andrei's "opBinary" proposal?
>
> I don't know -- I'm not proposing a solution to the  
> indexing-and-slicing-expression issues. Still, combining indexing and  
> slicing helps a little. But I don't yet know if the opBinary concept  
> will work.
>
> I think the problem of verbosity in operator overloads (opAdd, opMul,  
> ... all being nearly the same) is very unimportant and shouldn't be the  
> focus of attention. Two things matter:
> (1) expressivity; and
> (2) performance.
> If you don't have these two, your verbosity will be shot to pieces  
> anyway.
> This proposal, together with opDollar(), closes the last remaining  
> element of (1).

I agree.

-Steve