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.

Reply via email to