Thanks for pointing out that the design is intentional. The example from the documentation doesn't address the buffering issue, I am concerned with. A bufferless implementation would behave the same way. Try running this minimal test:

use Test::More tests => 1;
use Iterator;

my $value = 0;

my $iterator = new Iterator(sub { return ++$value });

is($value, 0, "Haven't called the iterator yet.");
[download]

The reason that I have raised this question is because I'd like to discuss the pros and cons of this design. What exactly is it that you get out of having a buffering iterator?

(I know that I have submitted a bug on this behaviour which was before I realized that the behaviour was intentional.)

If the price of being able to tell whether the iterator has been exhausted or not is buffering, then the price in terms of problems dealing with this buffering is way too high.

Another consideration is whether there is enough reason to implement iterators in a separate class, since perl offers closures that can be used to do almost everything Iterator has to offer.

All in all I want to discuss pros and cons of various iterator designs.