On Wednesday, 14 June 2017 at 16:17:50 UTC, Steven Schveighoffer
wrote:
I think opApply is kind of a forgotten piece of the language
since ranges have been introduced. We could resurrect it quite
easily this way, as opApply with template parameters that
return another range does not conflict with opApply that takes
a delegate. Easy to see if one works and if not try something
else. The huge benefit of this mechanism is to allow complete
control to the type over how it should be iterated, and not
have to fight the compiler.
You say "quite easily". I'm afraid this will linger. Please let's
not drop the ball on this, whatever the chosen solution is.
This is inherent of arrays working differently than ranges, but
being considered ranges via std.array. People consider slices
to be ranges, but they really aren't as far as the compiler is
concerned.
Sorry, I'm not seeing the connection. foreach is an abstract
iteration statement and we are just discussion if it is
reasonable for foreach to keep track of the iteration number.
I don't know if there is room to allow range-defined indexes
and foreach-defined indexes. foreach(a, b; someRange) has to do
one or the other. Otherwise, changes to how someRange operates
can make this a completely different operation.
Seems like exactly what we want. If you add a customization to
someRange to change the iteration behavior then each relevant
foreach automatically switches from the default to the requested
behavior. That's exactly the point of programming to abstract
interfaces.
