[galkk]

I disagree.

The doc states that range function returns an Array, so it looks like to iterate backwards you basically allocate array of indices and use those indices to get values from an original array. Not much better than reverting original array, if you will ask me.

Maybe there is some optimization for trivial scenarios, but the referred doc doesn’t mention it.

It really looks like python 2 case when you needed to remember that dict.items() returns copy and most of the time you needed iteritems().

[indigo945]

While that's true, the caveat here is that unlike Python, GDScript does not have a garbage collector. The main performance problem with creating an array copy in a soft-real-time application like a video game is usually not the allocation, but the additional GC pressure, which could cause frame jitter. GDScript does not suffer from that latter problem.

[nkrisc]

This is one of GDScript’s right spots for sure. But if this is the performance bottleneck (in a dynamic scripting language) you’re facing, then maybe that bit of code should just be a GDExtension, written in C++.

I would imagine for most games the performance impact from this won’t matter much.

[galkk]

The problem in this case is not the potential performance bottleneck, but the bad ergonomics for a dev, that leads to the complain. The rest is consequence.

And to me it looks like pure language/stdlib problem. Like for me, the proposed solution looks ugly both from syntax and what is going on behind curtains perspective.

I would rather not to code in a language that makes/tolerates decisions like that.

[nkrisc]

I mean if this one thing is enough to turn you off, you do you. I find GDScript to be 98% good for a dynamic scripting language.

Personally I’d just reverse the array and then iterate it. It’s going to make about zero difference.

Every language has its sharp edges.

[kragen]

cpython is slow enough that copying the list of keys was rarely a significant bottleneck