== for immutables should recursively call == on its fields

[StefanKarpinski]

This doesn't make much sense:

julia> immutable Foo{T}
         bar::T
       end

julia> Foo("baz") == Foo("baz")
false

julia> Foo("baz").bar == Foo("baz").bar
true

julia> Foo(1) == Foo(1)
true

If the fields are == to each other then the objects should be == to each other.

[StefanKarpinski]

I would also argue that for mutable types maybe we should throw an error in the absence of specialized ==.

[StefanKarpinski]

Tuples already do the right thing:

julia> ("baz",) == ("baz",)
true

[ivarne]

Arrays also behave this way

julia> {"abc",5} == {"abc",5}
true

julia> {"abc",5} == {"abc",4}
false

I am not sure if I think it is a good thing to introduce more differences between mutable and immutable types, but a default implementation of error for == on user defined types is something I like. How would you define == for different user defined types?

[JeffBezanson]

I can agree that the current default == is not clearly better than the one proposed here. Tuples are an easy case since we know they just "pass through" to their values. Throwing an error is certainly safe; in my view == depends on the abstract meaning of its arguments, so without a definition we really don't know what it means.

[ivarne]

If we throw an error if the comparison function is undefined, the code for comparing arbitrary objects will be longer.

try
    return a == b
catch
    return false
end

or

applicable(==, a, b) && a == b

[quinnj]

@StefanKarpinski, did this get implemented as part of the hashing changes? I seem to recall not needing == definitions for some immutable types after the changes.

[JeffBezanson]

Immutables already call === recursively on fields, so that might have been it. This hasn't been implemented.

[quinnj]

But doesn't this definition mean it is?

==(x,y) = x === y

[JeffBezanson]

That calls ===, which then calls === recursively. The issue asks for == to call == recursively.

[quinnj]

Ah, got it!