Clarify that resize doesn't initialize memory

[noidexe]

Some users might expect resize() to initialize added elements to zero. This clarifies that it is not the case.

Only relevant to 3.x since 4.0 handles it differently

[YuriSizov]

Assuming this is true, does it not apply to all the other Pool*Arrays?

[noidexe]

Assuming this is true, does it not apply to all the other Pool*Arrays?

Not all but all the ones using primitives (see #43033). Added the note for Int, Byte and Real

[noidexe]

#31040 also references the issue. This is fixed by #46476 on master by adding a fill(value) method but not yet backported to 3.x

[akien-mga]

"garbage" sounds colloquial and thus not really suitable for documentation. Or is that the official name of uninitialized memory?

[mhilbrunner]

I mean, its not really colloquial, see e.g. "garbage collection", but in this case IMO "and may contain random values" or "previous values in memory" would be better.

[akien-mga]

Commits should be squashed together, see PR workflow.

Concerns were addressed, but I cannot validate them myself

[akien-mga]

For the record, I checked and confirmed that those poolarrays contains random data when resized:

	var pba = PoolByteArray()
	pba.resize(10)
	for i in pba:
		print(i)
	
	var pia = PoolIntArray()
	pia.resize(10)
	print(pia)
	
	var pra = PoolRealArray()
	pra.resize(10)
	print(pra)


It can often be all zeros for me (especially byte and float), but not always.

(For `PoolByteArray` apparently print just prints `[PoolByteArray]`...)

[noidexe]

Getting all zeroes some times:
I'm not sure if the memory pool is initialized to zeroes when the game starts, but if it is it might be possible to be lucky and get resize to give you zeroes at first, but after a while you'll start getting garbage (i.e, memory that was used before).

"Garbage":
"Random values" is probably easier to understand than "garbage", "uninitialized memory", or any other technical term. The only problem is that it is not true. The values are not random. I'm worried someone might think it's a good way to get an array with random values.

[YuriSizov]

Random invalid values, maybe?

[noidexe]

Random invalid values, maybe?

They are valid, every arrangement of bits can be interpreted as a valid int or float, etc. And they are not random. "Garbage", or "garbage values" is the technical term.
resize() could initialize memory or not. This needs to be clarified.
Explaining what "garbage" is in the class reference would be like explaining what a variable is. I don't want to tell the user to RTFM but sometimes the terminology is unavoidable.

[timothyqiu]

For "random value", I've seen many people without programming background think it means "the system will generate a random value there" and wonder why it decides to make the effort to generate a random value instead of just putting a zero 🤣

If "garbage value" is colloquial, I suggest "indeterminate value". It's used in C/C++ standards to describe such values.

[akien-mga]

Explaining what "garbage" is in the class reference would be like explaining what a variable is. I don't want to tell the user to RTFM but sometimes the terminology is unavoidable.

I don't agree that "garbage" and "variable" are at the same level terminology wise (for the record, PVS-Studio uses "garbage" in quotes, which they wouldn't do with variable or memory - quotes denote that it's not a naturally flowing term even in this context). I do think here it can be worth explaining what it is, because we have many beginner programmers who may not be familiar with the terms. And translators may also mistranslate it if it's not crystal clear in the English string. If all users knew about garbage in this context, you wouldn't even need to specify further that "resize does not initialize newly allocated memory".

I suggest "may contain garbage, i.e. indeterminate values".

Edit: BTW maybe it should not say "may", but "will". It's guaranteed to be uninitialized, thus indeterminate/garbage.

[noidexe]

I suggest "maywill contain garbage, i.e. indeterminate values".

Thanks Akien and Timothyqiu. What I meant about variable is having to explain a term inside the class reference but "indeterminate value" is clear, accurate and short.
I'll commit the changes and make sure it complies with the PR workflow.

[akien-mga]

Thanks!