Arrays and Dictionaries should compare by reference, not element value

[vpellen]

Edit: My original argument for this was based in large part on the false beliefs that A) most languages compared containers by reference (C++, C#, and Python all seem to perform lexicographic comparisons), and B) that the mutable dictionary key issue was unknown. In fact, I found several references to the issue, dating back as far as 2018. Hahah whoops. Guess I should learn to do my research before going on a tirade. One of these days, I promise.

I've left this up for posterity but I can no longer seriously advocate for it.

---

I'm actually not sure how to go about arguing for this, because it's one of those things that seems obvious to me, but I'm going to try anyway.

Firstly, I am not a religious zealot. I recognize that I am not a beginner, and because of that, I have an intuition for pointers and memory and reference types and value types that a beginner will likely not have. I appreciate that I was once new, and I recognize that what I now feel is natural is not necessarily the best way to do things. There are many cases in programming where we do things out of convention or ritual without any real intent. However, I do not believe this is one of those cases.

The argument for compare-by-element-value is easy to understand: They appear the same, so comparison should return true. The problem is that two containers with identical elements are not actually interchangeable. The reason we compare reference types by reference is because we are, in effect, dealing with multiple views of a singular object, and it's the view that we're actually working with, not the data itself. C-style arrays are pointers, after all.

The argument for beginner friendliness is moot, because at some point the beginner will have to wrap their head around reference types anyway. For one, when we assign, we don't duplicate the contents. The duplicate function still exists. Every class derived from Object is also a reference type, so this isn't a concept they're going to be able to avoid for any length of time.

But really, I think the best argument I have for why it's a bad idea is within the language itself:

extends Node

func _ready():
	var arr_a := [12]
	var arr_b := [34]
	var dict := { arr_a : "A", arr_b : "B" }
	arr_b[0] = 12
	
	print(dict.keys(), dict.values())
	
	dict.erase(arr_a)
	dict.erase(arr_b)
	dict.erase([12])
	dict.erase([34])
	
	print(dict.keys(), dict.values())

Output:

[[12], [12]]["A", "B"]
[[12]]["B"]

G-g-g-ghooost keys!

The reason I'm not just submitting a bug report for this is because I think this is an architectural issue, not an implementation one. This is not a bug that should be fixed by replacing a bunch of ==s inside dictionary.cpp with calls to is_same, it's a bug that illustrates that this is why we don't compare mutable reference types by data state in the first place.

I think the main reason compare-by-element-value even has a practical use at all is because of GDScript's lack of ability to declare copy-by-value struct types, which are in fact quite a useful construct that I find myself wanting on a regular basis. But I suspect that's an issue that needs direct attention. Maybe we need tuples or something.

[Calinou]

Arrays and dictionaries were compared by reference in 3.x. This was changed in 4.0 to perform comparison by value by popular demand.

[vpellen]

My memory might be playing tricks on me - apparently == in both python and C++'s std::vector does a lexographic compare. I think C# does as well. So where the hell did I get the idea that == defaulted to an identity comparison?

In hindsight, maybe I will make a bug report for this.

Edit: Well this is embarrassing. I am not the first person to identify this:
godotengine/godot#24215
godotengine/godot#44471
godotengine/godot#60272