Status of multidimensional slicing

[Mason McGill]

Hi all,

I think D has a lot to offer technical computing:
   - the speed and modeling power of C++
   - GC for clean API design
   - reflection for automatic bindings
And technical computing has a lot to offer D:
   - users
   - API writers
   - time in the minds of people who teach

Multidimensional array support is important for this exchange to 
happen, so as a D user and a computer vision researcher I'm glad 
to see it's being addressed! However, I'm interested in hearing 
more about the rationale for the design decisions made concerning 
pull request #443.  My concern is that this design may be 
ignoring some of the lessons the SciPy community has learned over 
the past 10+ years.  A bit of elaboration:

In Python, slicing and indexing were originally separate 
operations.  Custom containers would have to define both 
`__getitem__(self, key)` and `__getslice__(self, start, end)`.  
This is where D is now.  Python then deprecated `__getslice__` 
and decided `container[start:end]` should translate to 
`container[slice(start, end)]`: the slicing syntax just became 
sugar for creating a lightweight slice object (i.e. a "range 
literal"), but it only worked inside an index expression.  If I 
understand correctly, this is similar in spirit to the solution 
the D community seems to be converging upon.  This solution 
enables multidimensional slicing, but needlessly prohibits the 
construction of range literals outside of an index expression.

So, why is this important?  One point of view is that 
multidimensional slicing is just one of many use cases for a 
concise representation of a range of numbers.  In more 
"specialized" scientific languages, like MATLAB/Octave and Julia, 
range literals are a critical component to readable, idiomatic 
code.  In order to partially make up for this, SciPy is forced to 
subvert Python's indexing syntax for calling functions that may 
operate on numeric ranges, obfuscating code (e.g. 
http://docs.scipy.org/doc/numpy/reference/generated/numpy.r_.html).

I point this out because it (fortunately) seems like D is in a 
position to have range literals while maintaining backwards 
compatibility and reducing language complexity (details are 
below).  I'd like to hear your thoughts about range literals as a 
solution for multidimensional indexing: whether it's been 
proposed, if so, why is was decided against, what its 
disadvantages might be, whether they're compatible with the work 
already done on this front, etc.

===================
Range Literals in D
===================

// Right now this works:
foreach (i; 0..10) doScience(i);

// And this works:
auto range = iota(0, 10);
foreach (i; range) doScience(i);

// So why shouldn't this work?
auto range = 0..10;
foreach (i; range) doScience(i);

// Or this?
auto range = 0..10;
myFavoriteArray[range] = fascinatingFindings();

// Or this?
auto range = 0..10;
myFavoriteMatrix[0..$, range] = fascinating2DFindings();

// `opSlice` would no longer be necessary...
myMap["key"];       // calls `opIndex(string);`
myVector[5];        // calls `opIndex(int);`
myMatrix[5, 0..10]; // calls `opIndex(int, NumericRange);`

// But old code that defines `opSlice` could still work (like in 
Python).
myVector[0..10]; // If `opIndex(NumericRange)` isn't defined,
                  // fall back to`opSlice`.

// `ForeachRangeStatement` would no longer need to exist as an 
odd special case.
// The following two statements are semantically equivalent, and 
with range
// literals, they'd be instances of the same looping syntax.
foreach (i; 0..10) doScience();
foreach (i; iota(0, 10)) doScience();

// Compilers would, of course, be free to special-case `foreach` 
loops
// over range literals, if it's helpful for performance.

On Wednesday, 12 March 2014 at 13:55:05 UTC, Kenji Hara wrote:
> 2014-03-08 10:24 GMT+09:00 Andrei Alexandrescu <
> SeeWebsiteForEmail at erdani.org>:
>
>>
>> I agree and sympathize.
>
>
> I finished to update my pull request #443. Now it is active.
>
> Kenji Hara