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.
