foreach range with index

[9il via Digitalmars-d]

On Wednesday, 14 June 2017 at 02:42:46 UTC, Luís Marques wrote:
> On Tuesday, 13 June 2017 at 21:44:43 UTC, Steven Schveighoffer 
> wrote:
>> But I think leaving the definition of the index up to the 
>> range itself is paramount -- I don't want every range to be 
>> able to have a size_t index, as that's not always what you 
>> want, and it conflicts with other items. What we may need is a 
>> smarter way to get from the type parameters at the front of 
>> the foreach to an iterable type.
>
> That's why I mentioned random access ranges, as in that case we 
> can sidestep this discussion; since foreach understands input 
> ranges, why can't foreach understand random access ones, and 
> iterate them as if they were slices, including maintaining a 
> foreach-generated index? That is, it would have nothing to do 
> with tuple unpacking. Plus, it would work transparently in the 
> cases you replace `slice` with `slice.algorithm`, where 
> algorithm maintains random-access. Instead of having to add 
> .enumerate in each place the slice (now a range) is iterated, 
> it would just work.

Random access iteration is more expensive then front/popFront in 
general case.
For arrays it is not true. But for many other kinds of ranges it 
is. For example ranges that do not have contiguous memory 
representation (strided vectors, flattened matrixes and etc)