foreach range with index

[Steven Schveighoffer via Digitalmars-d]

On 6/13/17 10:42 PM, 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.

Yes, foreach could be augmented to do that. However, this is essentially 
a way to implement enumerate without the .enumerate, and nothing more. 
It's not a lot of added benefit IMO.

What I'd rather see is a better mechanism for ranges (or things that 
provide ranges) to hook the foreach syntax to allow better control and 
power from ranges without using traditional opApply.

For example, if we had:

foreach(size_t a, b; x)

translates to:

for(auto _context = x.opApply!(size_t, void); !context.empty; 
_context.popFront)
{
    auto (a, b) = _context.front; // the way it works now with tuples, 
don't think there's a real syntax for this.
    ...
}

-Steve