Intended behavior of std.range.cycle?

[rcor via Digitalmars-d-learn]

On Thursday, 4 September 2014 at 11:58:58 UTC, monarch_dodra 
wrote:
> On Thursday, 4 September 2014 at 11:43:28 UTC, monarch_dodra 
> wrote:
>> Indexing is done with the unsigned size_t.
>
> I re-read your post, and I don't think I actually answered your 
> question...?
>
> I don't know of any case where you'd want to index negativelly. 
> That said, I'm sure it could be possible to wrap a cycle into a 
> simple "signed cycle" adaptor.
>
> There's one issue with what you want to do though: Who is 
> front, and where does your range start?

To give more detail:
I've been working on a strategy game. The player has 'next' and 
'previous' buttons they can use to cycle between units they 
haven't moved yet. I thought it would be cleaner to use a Cycle 
than to have the extra math necessary to wrap the index (its not 
that the math is terribly complicated, but it just makes things 
messier and less obvious).
In this case, "front" is arbitrarily chosen based on the order in 
which the units were loaded. It doesn't really matter who is 
front as long as each press of 'next' or 'previous' jumps to a 
new unit.
The "negative" index occurs when the player has unit 0 selected 
and presses 'previous'. Instead of jumping to the previous unit, 
the cursor sticks on the same unit (at least in the situation 
where size_t.max % numUnits == 0).

It's not a huge deal to work around it in my own code, but I 
figured I should point it out in case this was unintentional.