array slicing currently does not support steps?

[Paul Backus]

On Tuesday, 4 August 2020 at 13:15:39 UTC, jmh530 wrote:
> On Tuesday, 4 August 2020 at 07:39:04 UTC, Simen Kjærås wrote:
>> [snip]
>> Currently, a slice is essentially a (ptr, length) struct, and 
>> adding stride to the mix would require adding another field to 
>> every slice. This would break all D code ever, so we can 
>> disregard that solution.
> [snip]
>
> I think I've suggested something similar in the past. I don't 
> understand why another field is required as it would just be 
> some special syntax over indexing.
>
> For instance, I would imagine it used like
> auto x = [1, 2, 3, 4, 5, 6, 7];
> auto y = x[0..2..5];
> assert(y == [1, 3, 5]);

Currently, when you do `y = x[0..5]`, both x and y point to the 
same memory.

In order for `y == [1, 3, 5]` to be true, one of the following 
must hold:

1) y points to memory which contains 1, 3, and 5 in contiguous 
locations.
2) y has an overloaded == operator which takes the stride into 
account.

If #1 is true, then y cannot point to the same memory as x, which 
means a copy has to be made. If #2 is true, then y cannot be a 
simple int[], but must instead be a custom type that stores the 
stride in addition to a pointer and a length.

As WebFreak001 pointed out, you can get the "custom type" version 
with `x[0..5].stride(2)`, and the the "array with copied 
elements" version with `x[0..5].stride(2).array`.