Intended behavior of std.range.cycle?

[monarch_dodra via Digitalmars-d-learn]

On Friday, 5 September 2014 at 10:41:22 UTC, Vlad Levenfeld wrote:
> On Thursday, 4 September 2014 at 11:43:28 UTC, monarch_dodra 
> wrote:
>> *Should* cycle be negatively index-able? Personally, I don't 
>> think so. And even if it could, it has been proven non-size_t 
>> indexing is not well supported at all. It was de-facto chosen 
>> after the "iota-map fiasco" that all ranges be indexed with 
>> size_t and nothing else...
>
> Can you elaborate on what the problem was? I'm curious as I've 
> recently implemented a DSP module that uses ranges with 
> floating-point slicing and, other than having to define a 
> second kind of length (I call it "measure" so I can still have 
> a discrete length when I need it), it seems to work well enough 
> so far. It'd be bad if there were some unseen fiasco waiting 
> for me...

In itself, there is nothing wrong with having a "shallow 
container" that can be indexed from -inf to +inf. The "issues" 
might appear if you try to tag on the "range" interface on it.

In particular, who is "front"? If I do a "foreach" over the 
sequence, then will it miss half the elements? What does it mean 
to slice from -5 to +5 ? Which element becomes the "new" 0?

As for floating point indexing, it's the same thing. The indexing 
itself is fine, there's no problem there. But if you popFront, 
how many elements are you actually skipping over. What would it 
mean if I were to "take(4.5)" elements?

*Overall*, it should be fine, but if you are creative, you could 
hurt yourself. I don't know your exact use case though.

So my conclusion is mostly that as long as you only index, you 
should be fine. Mix in range adaptors, and things *could* become 
less stable. *could*. But you should still be mostly safe. Again, 
depends on use case.