More on rotate

Evolution Pitches
1

This branches off “Blasts from the past: algorithms.” Hopefully we’ll have a rotate(toStartAt:), and maybe a rotate(toEndAfter:). Those use an endpoint to base the rotation amount, instead of an number. Maybe we should have an count-based rotate too.

  • rotate(towardsStart count: IndexDistance)
    • Acts like rotate(towardsEnd: -count) when count < 0.
    • No-op if self.count <= 1.
    • Does rotate(toStartAt: index(startIndex, offset: count % self.count)).
  • rotate(towardsEnd count: IndexDistance)
    • Acts like rotate(towardsStart: -count) when count < 0.
    • No-op if self.count <= 1.
    • Does rotate(toEndAfter: index(endIndex, offset: -((count + 1) % self.count))).

The methods besides rotate(toStartAt:) could be hard-coded extension methods. I don’t know if the remaining one should be hard-coded, or a potential override point.

2

What’s your use case for these? And why include these in the standard library?

It would seem to me that if rotating by offset is the more useful variant, then that should be the only version in the standard library; and if not, it shouldn’t be in the standard library. It seems that it’s trivial to write any of these overloads in terms of the others.