While I'm sympathetic to the argument for lists, I think it would probably be a breaking change at the current time. It is possible that there are uses of lists as set elements/map keys that rely on the current identity behavior.

Removed Type-Defect label.
Added Type-Enhancement, Library-Core, Area-Library, Triaged labels.

Given that lists in Dart are mutable there is no good way to compute a hashCode that wouldn't take linear time.
If you need a map that compares lists deeply, pass the appropriate functions to the Map constructor (https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-collection.LinkedHashMap#id_LinkedHashMap-).
The collection package has functions that compute deep hashcode/equality which can be used for this.

This comment was originally written by dharcourt@chromium.org

#­2: This complexity would be avoided if List's == operator checked the types of the compared lists and returned true only if they were the same. This would makes sense anyways because List subclasses may have additional attributes and characteristics that make them different from other types of list even if they contain the same elements in the same order. With this definition, in the first case presented in comment #­2 (List vs. List<int>) the lists would be equal since the generics wouldn't change the fact that both lists are List instances containing equal elements in the same order, and in the second case (List vs. OtherUsefulList) the lists would be unequal since they're lists of different types. List subclasses wouldn't need to override == unless either: a) They wanted to be comparable for equality to other types of list; or b) They wanted to take into account for equality more than just list type equality, list element equality, and list element order.

#­3: I think the explanation in the previous paragraph should clarify things. Apologies if the original submission was not clear enough. Please ask if questions remain.

#­4: Would it be a problem to have an O(n) hashCode for Lists in Dart? Java has this behavior and I haven't heard of it being a problem. Also, thanks for the pointer to the custom hash functions in map and set constructors, I hadn't considered those.

All of this may be somewhat moot because changing this directly would be a breaking change, as noted in #­1. Is there any way to have the benefits of content based List equality and hashing without backward compatibility issues? It would be nice to avoid custom hash functions for maps and sets and the use of ListEquality, which don't make for beautiful code.

It's interesting to consider that in this respect Strings, which are sequences of characters, don't behave the same as Lists representing the same sequence of characters. Apart from anything else, it seems like it would be an improvement to converge those behaviors towards String's simpler one.

This comment was originally written by dharcourt@chromium.org

#­7: I think you misunderstood my comment: I wasn't claiming that strings were lists of characters. Re-read the comment and feel free to email me if any questions remain.