Add Iterators and use them for for

[est31]

Fixes #3765 . I believe this is a great addition and speedup for GDscript.

The PR does three things, in three commits:

1. Integrate commit by @sheepandshepherd to add a RangeIterator class. Many thanks to @sheepandshepherd for writing the class!
2. Add a built in xrange function similar to the one in Python 2, and document the function
3. Replace range with xrange for for loops. This is guaranteed to be 100% backwards compatible, unless you relied on for i in range(...) to allocate memory xD... I'm not really proud of how I hacked the parser to do it but this is most conservative regarding backwards compatibility. Note that the GDParser::_reduce_expression method does stuff like this as well, so I guess its fine. It catches 99% of all uses. Or do you know somebody who assigns range to a variable and then loops over the variable?

[est31]

I'm not sure -- is this the right way to allocate? It works, that's great, but does it leak memory?

[sheepandshepherd]

It leaks, yes. I made it a Reference because I couldn't find any convenient location to call memdelete. To fix it, replace the allocations with Refs:

Ref<RangeIterator> itr = Ref<RangeIterator>( memnew(RangeIterator) );

[sheepandshepherd]

I like the range optimization, actually. Replacing GEN_RANGE with GEN_XRANGE in for loops is a clean way of using the iterator and staying backwards-compatible.

One more thing -- the first RangeIterator had some naming convention mistakes and other issues that I meant to fix in a second commit. You might want to add it, but it does rename _set_range to set_range in C++ (the one with the underscore was supposed to be the GDScript version with Variants).

[est31]

Thanks, the new commit is now added.

I've squashed two commits, to keep the history clean.

[bojidar-bg]

👍

[alketii]

Wow, this is awesome, please merge.

[reduz]

Please revert this, let me review it properly first

[reduz]

Also please don't merge anything related to GDScript without me reviewing it first

[akien-mga]

Reverted by #3894.

[vnen]

@est31 could this code be sent as a new PR? I think it's a nice addition and the code does not seem bad. It might be forgotten here as a merged PR.

This would also be a start for list comprehension asked in #4716.

[est31]

@vnen the code does not look bad, I agree, but it turns out to be slower, by a large factor. That's why it was reverted.

[sheepandshepherd]

The overhead of calling an Object's _iter_next method for each iteration is one reason this way is much slower (here, in variant_op.cpp), compared to the really simple code for Array a few lines below that.

The only way this iterator could be as fast as an Array is if we modify the for loop to call its _iter_next function from C++ instead of through GDScript. I haven't looked at how the GDScript for loop works though, so I don't know if this is possible.

[bojidar-bg]

@sheepandshepherd Calling the function directly would essentially break custom iterators built in GDScript.