Consider a call chain(r1, r2, r3, ..., rk, ..., rn) where range rk is infinite. Then that should return the same exact result (type and behavior) as chain(r1, r2, r3, ..., rk). This is because chaining effectively stops at the infinite range and simply continues with it forever.
Obviously a good case is chain(r1, r2) which simply returns r1 if infinite.
An alternative would be to refuse compilation - this use may be a bug more often than not. Thoughts?
Comment #1 by schuetzm — 2016-04-15T18:20:48Z
Not sure about refusing compilation - things like this could appear in otherwise valid generic code...
Anyway, bidi ranges need special treatment - they need to be accessible from the end up to the last infinite range, too.
Comment #2 by andrei — 2016-04-15T18:28:52Z
@Marc didn't think of that. But then what do you do when you come back and you finish the bidir ranges after the infinite one. So then you have a non-empty range that you can't pop back from anymore. The mind boggles...
I agree about refusal to compile - let it ride!
Comment #3 by schuetzm — 2016-04-15T19:23:13Z
Ah... I now remember the restriction that infinite ranges cannot be bidirectional. I think this was a conscious decision in order to get a simpler range hierarchy, but there was no fundamental reason to disallow it, right?
This restriction simplifies things for chain(): if any of the individual ranges are infinite, the resulting chain cannot be bidirectional.
Comment #4 by robert.schadek — 2024-12-01T16:26:34Z