godot: Exported (non-static) Arrays are not duplicated when instancing.

This behavior conflicts with all other properties, and is contrary to the OOP model Godot uses.

I can’t see what exactly is your point because it’s just an expected behavior in OOP.

You can try to reproduce it using Python.

You can “avoid” this behavior initializing the array in the init/ready method.

In the export var case, you can just leave the variable empty (null), so in the following code the array will be unique:

extends Node

export(Array) var test

func _ready():
	if test == null: # if the array is "empty" in the inspector it will be kept as null
		test = []
	test.append("test %s" % self)
	print(test)

However, I think it’s an inconsistency in gdscript implementation because both var and const should share objects created before initialization. In this case only const is being shared.

Additionally, and ancillary to this, when instancing a node in the editor with an exported array on it, the array is not duplicated, leading changes to the array on one (child) node to be applied across all instances and even the original scene. This is an unacceptable behavior, for very obvious reasons.

If this was fixed in 4.0, it seems there was a regression at some point:

extends Node

@export var array: Array[String]

func _ready():
	array.append(get_name())
	await get_tree().process_frame
	print("array in %s: " % get_name(), array)

<start> was added in the inspector in the NonEmptyArray scene to trigger the issue. I expected NonEmptyArray to print ["<start>", "NonEmptyArrayX"] instead of all the nodes, like in the EmptyArray case (sans <start>).

Full project: ArrayRegression.zip

If intentional, https://github.com/godotengine/godot-docs/issues/5640 should be extended to 4.X docs as well.

Edit: the issue also happens in 4.2 dev 5

@williamd1k0: I can’t see what exactly is your point because it’s just an expected behavior in OOP. You can try to reproduce it using Python.

You are correct that this is an expected behavior in Python, but that’s because variables declared with that syntax reside in the class, not the instance, and are initialized at declaration time.

What you describe is the realm of static member variables in almost all OO languages (C++, C#, D, etc.), which brings me to my next point; In GDScript, static member variables are explicitly disallowed:

A function can be declared static. When a function is static it has no access to the instance member variables or self. Ref

Static functions are allowed, but not static members (this is in the spirit of thread safety, since scripts can be initialized in separate threads without the user knowing). In the same way, member variables (including arrays and dictionaries) are initialized every time an instance is created. Ref

In GDScript, the correct behavior is that all variables are instance-local and should be initialized upon initialization of the script (i.e. just before the _init() method).

@bojidar-bg: Likely will be still unsolved after #17382, but that PR might be a step towards fixing it.

If it does what I think it does, it should fix half the problem.

The ideal solution (AFAIK) is to make instances have a copy-on-write property in the editor, and otherwise duplicate the value at runtime. This will allow changes to the parent scene’s copy to properly propagate, while allowing every instance their own copy.

Yeah, there may be a good reason for it, but I agree it’s definitely surprising. I wonder if it would be possible to find more use for the static keyword. GDScript is very much a class language. Would make sense to have static variables.

In GDScript, the correct behavior is that all variables are instance-local and should be initialized upon initialization of the script (i.e. just before the _init() method).

This!

I can’t see why specifically array should work differently from everything else. All other exported variables and node specific properties (Size, Position and so on) are instance-local!

And again, this behaviour has changed since 2.x, what is the logic behind this change?

Can confirm in 4.1.3. even while being documented earlier this behavior is a huge gotcha that feels out of place compared to how a user would expect a variable to behave.

Also I’d suggest updating the docs with a warning about this until it’s fixed because as of now there is no mention of it which only adds to the confusion

This design decision is just confusing. Why is every variable local except of arrays? Does not make any sense.

This is the expected behavior according to the doc. Though I don’t know the reason for that.