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.
Hmm, I suppose that even if we have all of the good stuff of
length, opIndex, opSlice, etc., we can't assume the indices are
[0..length], right? But there should be some way for, say, map to
preserve that information from the slice, the same way random
access is preserved.
