Crystal: Iterator idempotence

[KimBurgess]

The Iterator module has a number of methods inherited from Enumerable that when invoked result in the original iterator being exhausted. This can lead to some confusing behaviour when first encountered.

For example:

iter = (0...100).each

puts iter.size # => 100

puts iter.to_a # => []

puts iter.size # => 0

Similar behaviour also results from calls to #all?, #any?, #count, #none? and #one? due to internal calls to #each, which forces full evaluation of the original sequence.

Two possible solutions may exist here:

1. Make note of this behaviour in the docs to help reduce WTFs/minute.
2. Override these methods within Iterator so that calls become idempotent. This would likely require internal caching of generated elements so that subsequent calls involving #each are yielded the originally generated objects. There's an obvious resource impact here as well as change to existing API behaviour so this comes with it's own challenges.

Happy to put together a PR for either of these, but would be interested in some feedback on the preferred approach.

[straight-shoota]

Implicitly caching an iterator is not an option as it entirely defeats the purpose of an iterator (which can have a potentially unlimited size). When such behaviour is needed, it should be implemented by deliberate choice, for example by solidifying into an array.

So we can only improving the documentation on the behaviour related to re-iterating an iterator.

[KimBurgess]

Possible counterpoint to that is full evaluation and caching does already take place with calls it Iterator#cycle. But I do completely agree that this is dangerous territory.

[straight-shoota]

#cycle is a single method and caches only for its internal behaviour.