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)
