Sorry for resurrecting this, but I figure this is the best place to discuss it:

Shouldn't we make the `r[0 .. $]` mandatory for an infinite ranges to satisfy `hasSlicing`?

Rationale is:
* Infinite ranges with hasSlicing is new, so we shouldn't be breaking code.
* The compiler will simply *never* be able to automatically generate opDollar for them.
* Range adapters that want to implement slicing for infinite ranges *must* rely on the range providing `r[i .. $]`.

This is because the adaptor cannot return the type `Adaptor!(Take!Range)`, as it has to return the type `Take!(Adaptor!Range)` to verify has slicing (this has actually turned out to always be a good thing, in my short experience with this).

Once you take this into account, the only way to implement the adaptor's `opSlice` operation is to "fast forward" the internal range (`r = r[i .. $]`), and then return `r.take(j - i)`.

either that or remove the static condition of `typeof(take(r, 1)) s = r[1 .. 2];`. But I think this requirement is both brilliant for template programming, and the requirement actually forces you to use some very clean implementations.

--------
This question is asked in the context of a zip of slice-able infinite ranges.

If the `opSlice` operation returns a `Zip!(staticMap(Ranges, Take))`, then zip will fail the `hasSlicing` condition. It *must* return a: `Take!(Zip!Ranges)` (this is a good thing actually: Take of zip should be *much* more efficient than zip of takes).

Problem: As explained above, to implement such slicing, zip will need to first slice the internal ranges from i to $. Testing if a range has opDollar is already kind of complicated, and heavily complexifies the implementation (did you see my "chunks" improvement?).

In the context of multiple ranges, just writing the condition of `static if ("all ranges are infinite and all of them provide slice to end")` is close to nightmarish...

----
Thoughts? We can take it to newsgroup if you feel it requires more discussion.