• Timothee Cour (58/58) Apr 06 2013 Currently x[a...b] calls opSlice(a,b);
• bearophile (10/20) Apr 06 2013 Don has discussed about this more than one time. Generally I

Timothee Cour <thelastmammoth gmail.com> writes:

Currently x[a...b] calls opSlice(a,b);

This has several drawbacks:

* it breaks _orthogonality_ of features: opIndex should work with
everything (indexes, slices), whereas now we're having an opSliceIndex
that works on slices and opIndex that works on non-slices.

* one can't have multiple slicing / indexing for multiple dimensions, eg:

x[a..b,c..d]
x[a..b,c]
etc.

* it makes it hard to forward slicing arguments across function calls, eg:
auto do_slicing(T)(T slice){
  return x[slice] + y[slice];
}
do_slicing(1..2);

* it makes it hard to support future slicing functionality such as stride, eg:
x[begin..end:stride]

--------
My current workaround in my multidimensional array library is to use a
proxy for slices, eg:
x[R(1,2), 3]
x[a, R(), R(a,b), R(10,$), R(a,b,s)] //exaggerating, just to show the
different options

But those would benefit from syntactic sugar as:
x[1..2, 3]
x[a, .. , a..b, 10..$, a..b:s]
which is easier to read. (the second empty ".." is questionable;
matlab's ":" seems good too).

--------
So my question is:
why can't "a..b" be syntax sugar for a struct, as follows:

Slice(T){
  T begin;
  T end;
}
auto slice(T begin, T end){
  return Slice(begin,end);
}

SliceStride(T,T2){
  T begin;
  T end;
  T2 stride;
}

auto slice(T begin, T end, T stride){
  return SliceStride(begin,end,stride);
}

auto mySlice=10..12; // syntax sugar to call slice(10,12);
auto mySlice=10..12:-2; // syntax sugar to call slice(10,12,-2);

Now making generic code in libraries is trivial:
auto opIndex(T1, T2)(T1 a1, T2 a2){
static if(isSlice!T1){...} else {...}
static if(isSlice!T2){...} else {...}
}

Also, compiler should be able to optimize out the underlying slice
object constructions, so it'd be exactly as efficient as current
scheme.

Same thing goes to opSliceAssign.

Thanks for your feedback,
Timothee.

"bearophile" <bearophileHUGS lycos.com> writes:

Timothee Cour:

 * it breaks _orthogonality_ of features: opIndex should work 
 with
 everything (indexes, slices), whereas now we're having an 
 opSliceIndex
 that works on slices and opIndex that works on non-slices.

Don has discussed about this more than one time. Generally I 
think there is space for improvements in the D design.

If you want bring this topic in the main D newsgroup, but keep in 
mind this was already discussed one or more times.


 * it makes it hard to support future slicing functionality such 
 as stride, eg:
 x[begin..end:stride]

I think a stride is important.


 Also, compiler should be able to optimize out the underlying 
 slice object constructions,

If the slice is a small struct, it's about as efficient as normal 
arguments.

Bye,
bearophile