D2 Short list -- opSlice

[Don]

Denis Koroskin wrote:
> On Thu, 19 Nov 2009 11:53:51 +0300, 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]).
>>
>> Since fixed-length arrays are now passed by value (yay!) this would be 
>> just as efficient as the current method. It'd be simple to implement.
>>
>> Downsides: (1) Arguably not terribly intuitive.
>> (2) This would not let you have a slicing from A..A, while 
>> simultaneously allowing indexing by A[2]. But I don't think that makes 
>> sense anyway -- what would $ return? (Note that it doesn't stop you 
>> from having indexes of type A[2], and slice from A[2]..A[2], which 
>> might be important for containers of 2D vectors. It's only the case 
>> where indexing and slicing are different types, which is prohibited).
>>
>> This is the only solution I have which doesn't introducing more 
>> coupling between the language and standard library.
>> Another possible solution is to define a special Slice struct in 
>> std.object; downside is that it creates yet another pseudo-keyword.
>>
>> A third solution would be to use tuples;  currently I think it's 
>> impossible, but if tuple auto-flattening is removed there may be a 
>> chance. Even so, it might be a little clumsy to use.
>>
>> A fourth solution is to retain the status quo, and not provide the 
>> multi-dimensional slicing feature <g>. This is actually about the same 
>> amount of work as option (1), since opDollar would need to work for 
>> opSlice (I only implemented it for opIndex).
> 
> I'd like for a..b to be auto-magically rewritten into range(a, b).

That's solution (2), but applied everywhere. One nice thing about that, 
is it would allow slices as function parameters. I've wanted that for:

testall(&sin, &asin, -PI..PI);

The downside is that you have to add this slice/range creature into 
std.object.
(BTW, note that $ would still only be allowable inside opIndex 
expressions. I can't see how it could be made to work in general, it's 
too uncertain which dimension you are referring to, especially in a 
variadic function).