Fix for the very common infinite loop issue, when forgetting to call getIterator #11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I find that when using this library, it is very common to accidentally create infinite loops like this:
Instead of properly doing this:
I think this is because when the for loop is given a table that has __call metamethod, it assumes it is a normal iterator function, and repeatedly calls it, causing a new iterator function to be created each iteration of the loop. Otherwise it would just produce an error instead of an infinite loop.
For some lua environments an infinite loop is much worse than just triggering an error. We can detect this mistake though, since when lua calls the given iterator function it passes in two parameter values. So we can differentiate between when the lua for-method calls it and when the user calls it themselves.
I am using select() because the parameter values are passed as nil values, so #{...} would return 0