Why doesn't the Array Equality Function Work as Expected?

Question

In Programming in Scala the authors write that Scala's == function compares value equality instead of reference equality.

This works as expected on lists:

scala> List(1,2) == List(1,2)
res0: Boolean = true

It doesn't however work on arrays:

scala> Array(1,2) == Array(1,2)
res1: Boolean = false

In Programming Scala the authors recommend to use the sameElements function instead:

scala> Array(1,2).sameElements(Array(1,2))
res2: Boolean = true

As an explanation they write:

While this may seem like an inconsistency, encouraging an explicit test of the equality of two mutable data structures is a conservative approach on the part of the language designers. In the long run, it should save you from unexpected results in your conditionals.

1. What does this mean? What kind of "unexpected results" are they talking about? What else could I expect from an array comparison than to return true if the arrays contain the same elements in the same position? Why does the equals function work on lists but not on arrays?

2. How can I make the equals function work on arrays?

Answer 1

It's all about referential transparency. The idea is, if two values are ==, it shouldn't matter which one you use for something. If you have two arrays with the same contents, it clearly matters which one you modify, so == returns false unless they are the same one.

Answer 2

This exact question has been voiced many times (by myself too, see http://stackoverflow.com/questions/3213368/strange-behaviour-of-the-array-type ).

Note that it is ONLY the Array collection that does not support ==, all other collections do. The root cause is that Array IS the Java array.

Answer 3

It is true that the explanation offered in the book is questionable, but to be fair it was more believable when they wrote it. It's still true in 2.8, but we have to retrofit different reasoning because as you've noticed, all the other collections do element comparisons even if they're mutable.

A lot of blood had been shed trying to make Arrays seem like the rest of the collections, but this was a tremendously leaky abstraction and in the end it was impossible. It was determined, correctly I think, that we should go to the other extreme and supply native arrays the way they are, using implicit machinery to enhance their capabilities. Where this most noticeably falls down is toString and equals, because neither of them behaves in a reasonable fashion on Arrays, but we cannot intercept those calls with implicit conversions because they are defined on java.lang.Object. (Conversions only happen when an expression doesn't type check, and those always type check.)

So you can pick your explanation, but in the end arrays are treated fundamentally differently by the underlying architecture and there's no way to paper over that without paying a price somewhere. It's not a terrible situation, but it is something you have to be aware of.