Remove Packed Arrays in favor of Statically Typed Arrays

[ettiSurreal]

I am not sure about the scale or even possibility of this. This is just something I wanted to bring up in case there is any interest.

Remove the 9 PackedArray classes in favor of simply using var arr: Array[type] as introduced in Godot 4. Tightly packed memory functionality would be moved into it.

Potential regressions:

• No longer possible to do 32-bit float and int arrays, with no obvious way to solve it.
• No longer possible to nest multiple packed array types?

[kubecz3k]

Not sure, but probably not the best idea given those structures are often used in context of network communication

[AThousandShips]

Unless it would just be syntactic sugar it would impact performance and usability, even ignoring the limitations of removing the sized int and float arrays

[AThousandShips]

Packed arrays are quite different and it would be a lot of work to just drop in replace the specific arrays with them, otherwise they'd be different from the rest of the typed arrays which would be confusing

The packed arrays exist for performance reasons and don't use the array types underlyingly, which is why they are more limited in what they can do

[Calinou]

Last time I ran https://github.com/godotengine/godot-benchmarks locally during the 4.0 RC stage, packed arrays were significantly faster to create and modify than typed integer or string arrays.

[SlugFiller]

The main difference between the two is that packed array are "passed by value" using copy-on-write logic. This allows, for example, for a node to pass a PackedVector2Array to the RenderingServer via some method call, and, immediately after, modify the array and use it for something else, without causing errors in rendering. The RenderingServer is guaranteed that the version it got is non-mutable from the outside.

And vice versa. If the RenderingServer modifies the array somehow, it doesn't effect the caller. This is particularly important for arrays used as long-term cache, to prevent cache corruption.

Typed array don't have that property. If you pass a typed array, it's passed by reference, and is mutable. The data inside it can be corrupted by both caller and callee. It doesn't and can't provide the same guarantees as a packed array.

[dalexeev]

The main difference between the two is that packed array are "passed by value"

No, in 4.0 this has been changed:

# 3.x
var a := PoolStringArray()
var b := a
a.append("test")
prints(a, b) # [test] []

# 4.0
var a := PackedStringArray()
var b := a
var c := a.duplicate()
a.append("test")
prints(a, b, c) # ["test"] ["test"] []

[SlugFiller]

Odd. The code shows Vector<T> specifically being backed by a copy-on-write data structure (CowData). It was my understanding that PackedXArray was backed by Vector, but it seems to not be case.

At the very least, when calling something like CanvasItem.draw_polygon, the points parameter is converted from PackedVector2Array to Vector2<Point2>. Indeed, in core/variant/variant.h, it is defined as typedef Vector<Vector2> PackedVector2Array;.

I can tell that duplicate is done very efficiently:

	Vector<T> duplicate() {
		return *this;
	}

Until a value is changed, the buffer isn't copied. Simply referenced.

By contrast, TypedArray simply inherits from Array, and adds typechecking. It's not really "typed" in the classical sense.

[AThousandShips]

It looks like the the Packed*Array are referenced by pointer internally in Variant so no COW directly between two Variant without duplicate, but when duplicating a new reference is made

And yes when it's accessed as Vector<T> in C++ it is fully COW so there's a barrier there