This page used to specify that GetChildren() returned children ordered by which objects had been added (parented) to the object first. Now it says the order is unspecified. Which is it? Is code that relies on the behavior that GetChildren() returns children that were parented first in the first indices stable? If not, then the breaking change should be explicitly documented.
Affected URL: https://create.roblox.com/docs/reference/engine/classes/Instance#GetChildren
Hello @asadefa . Thanks for reaching out!
The GetChildren() documentation was updated to reflect actual behavior as the method doesnāt always return in the expected order. This isnāt a change in engine functionality, rather a fix to the documentation to resolve an inaccuracy.
As mentioned in the documentation, the recommendation is to perform manual sorting instead of relying on the returned order.
Note that the array is not sorted in any particular order, so manual sorting (for example using table.sort()) is advised for sorting the children returned by this method.
While no actual behavior was changed, Iāll see where we can surface this documentation fix in other avenues to make more creators aware (this bug report helps!). I appreciate you double checking with us and please reach out if you see any other inconsistencies.
Have a great day,
naahchos
Based on my testing and older documentation I could find, GetChildren() will return a consistent order as long as the objects were placed into the parent in the consistent order. However, when children are replicated to clients, their replication order might be non-deterministic or random, so GetChildren() on the client might return a different order than on the server, even if the server ordering is deterministic. Can you determine if the above is the reason why GetChildren() sorting has been updated to say ānon-deterministicā? If so, then the documentation should be updated to say, āYes, the order is consistent on the server or client-created objects, but replication order is non-deterministic.ā
Hi @asadefa .
Iāll reach out to the individual who made the documentation change to see if they want to include your suggestion. Itās possible that this specific sorting behavior is not something that Roblox can guarantee will remain static now or in the future, even if your own tests seem to be consistent.
Iāll make sure to update the documentation if I hear anything differently. Thanks!
Hi! That individual, here! Weāve always had the stance that this order can change at any time, but the documentation incorrectly reflected that (as naahchos said).
The reasoning here is that we reserve room to make optimizations in the future, so that order may change, and we donāt want people relying on specifics. Ideally, the table is a set, but since those donāt really exist in Luau, we canāt have the return type reflect that. We donāt want to document any particular order because that would lead developers to think that they can rely on the behavior not changing, not because we donāt know the specifics of what order :GetChildren() returns.
Thanks for the reply, but my concern is that since that was documented at some point, there may be some unknown amount of legacy code that does rely on the previously documented order, despite us now learning that we should not rely on the order. By not having the order documented anymore sort of opens the door to code that was āguaranteedā to work at the time the specific ordering was documented but could break at a future time.
I feel that for the purpose of preserving legacy code that, at the time, was āto the letterā correct, the order should be preserved and documented. If there is an unordered but more optimized function added in the future, that should probably get a new function. GetChildrenFast(), GetChildrenUnordered(), etc.
Or if you still do not want to do that, I would add a note in the documentation that says something like:
Warning: Currently
GetChildrenreturns children by the order their parent was set to the object, but this behavior could change at any time and should not be relied on.
This would make the documentation change more transparent and document the current behavior without making a long-term guarantee.
To my knowledge, the documentation wasnāt incorrect for too long, and any code that was written with it in mind was never guaranteed to work, even if it followed this documentation to the letter. Like you said, there are situations, like replication, where code could look like it works and then break under different circumstances. Weāve had this stance for as long as :GetChildren() has existed, and it was documented at once point, to my knowledge. Iāll check with the docs team to see when the old sentence specifying the ordering was introduced, but saying anything about the ordering on the docs page feels like it gives information that we explicitly donāt want developers to use.
At this time there are no plans to change the ordering of :GetChildren() for the basic case, and there will certainly be internal talks if we ever do want to change it, as well as case studies and profiling to see what, if anything, breaks. We may determine that we shouldnāt change the order regardless, depending on the cost. We likely wouldnāt introduce multiple :GetChildren() methods- if thereās a reason to change the order for optimization, we want all games on the platform to get that optimization.
I believe the documentation change was made at most a few months ago, and I found some archives going back to 2019 documenting the explicit ordering: Instance:GetChildren
Although I might not be able to find older archives at the moment, the documented ordering might go back far earlier than 2019.
Ok that is pretty old, dang. Hereās a post from 2018 clarifying the correct behavior:
Rest assured though, if thereās ever discussion about changing the behavior the community will be notified to get input.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.