(Why is -1 the magic “all value” for .count and not 0? Retrieving zero values does not ever appear to be useful.)

(Why is -1 the magic “all value” for .count and not 0? Retrieving zero values does not ever appear to be useful.)

I guess there's a historical reasoning behind. Should it be refactored? I agree with you, but I'm afraid this kind of bug is used as a feature.

Should it be refactored? I agree with you, but I'm afraid this kind of bug is used as a feature.

It's not explicitly documented, but given the default values, I consider this a feature: https://www.php.net/manual/en/limititerator.construct.php

I just wanted to complain without expecting any changes (that's why that remark was in parentheses).

I just found out that there another test with a similar test case: https://github.com/php/php-src/blob/7e5ad5caf8e249453a84b4f62565188cf69b877f/ext/spl/tests/gh18421.phpt.

Throwing in the constructor means that the OOB exception becomes a ValueError (like LimitIterator::__construct(): Argument #3 ($limit) combined with the offset would cause integer overflow). I guess it would be a BC break to have this in 8.3, so I'm not sure how to proceed. The constructor of LimitIterator already throws many ValueError so it feels wrong to add a OOB exception here?

I pushed a new version with your suggestion @Girgias, is that what you had in mind?