Michael Zedeler wrote:
This is exactly why I keep writing posts about Ranges being defunct as
they have been specified now. If we accept the premise that Ranges are
supposed to define a kind of linear membership specification between two
starting points (as in math), it doesn't make sense that the LHS has an
additional constraint (having to provide a .succ method). All we should
require is that both endpoints supports comparison (that they share a
common type with comparison, at least).
To squint at this slightly, in the context that we already have 0...1e10
as a sequence generator, perhaps the semantics of iterating a range
should be unordered -- that is,
for 0..10 -> $x { ... }
is treated as
for (0...10).pick(*) -> $x { ... }
Then the whole question of reversibility is moot. Plus, there would then
be useful distinction for serialization of C<..> Vs C<...>. (perhaps we
should even parallelize) When you have two very similar operators it's
often good to maximize the semantic distance between them so that people
don't get into the lazy habit of using them without thinking.
