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
