Surprising struct equality test

question

#1

By my understanding of structs, they should be compared by value by default. So what is going here??

struct T
    name::String
end

T("hello") == T("hello")

returns false!


#2

The fields of a struct are compared using === (object identity). "hello" === "hello" is false. But you’re not alone in finding the behaviour counterintuitive:


#3

This is because

julia> "hello" === "hello"
false

Mutable members compares through object identity by default.


#4

Is there a way to modify this behavior for my struct? Can I “redefine” equality somehow?


#5

Hmmm, I am confused. Why isn’t "hello" === "hello"? Why strings don’t behave like values?


#6

You can redefine Base.:(==), but it may break some implicit assumptions in existing code, also, you need to define hashing. For the moment, you are better off defining your own equality operator. I posted an example in a parallel topic.


#7

Thanks. I did this:

Base.:(==)(x::T, y::T) = x.name == y.name

Why do you say that could “break some implicit assumptions in existing code”?
And you think I have to define hashing in this simple example (my type is literally this simple)? How?
Thanks!


#8

A function could rely on existing behavior of ==. If you change that, you could break code.

Your code is nonsensical, and won’t even compile.

As for hashing, see the manual. Or as an example,


#9

What do you mean it won’t compile? I have it right here ant it works. Do you get an error??

Note that I am defining == only for my type T … I don’t see the danger, maybe I am missing something?


#11

I thought T was a type parameter, which should have required a where T. If it is a concrete type, which has a field name, then it should work.


#12

Ah yes, sorry. I was using the T I defined in the first post.


#13

This is very unintuitive:

struct T1 s::String end
Base.:(==)(x::T1, y::T1) = x.s == y.s

struct T2 i::Int end
struct P x::T1 end
struct Q x::T2 end

@show T1("hola") == T1("hola");   # true
@show P(T1("hola")) == P(T1("hola"));  # false (!)
@show Q(T2(1)) == Q(T2(1));  # true (wtf)

How can I fix this? I want my T1 to behave like a true value. Overloading == on T1 is not enough, as you can see from this example. I would have to re-define == on P as well (and all composite types that contain T1, which is impractical). And overloading === of T1 seems to be forbidden (I get an error).

@Tamas_Papp @cstjean @yuyichao (help me :slight_smile: )


#14

The answer is in the very first response you got. Also, note that pinging people for no good reason is considered impolite.


#15

Sorry, but I do not see how that fixes the problem? I mean a workaround to make T1 behave as a true value type, in spite of the string field. Care to explain?


#16

Strings are for implementation reasons defined as a mutable struct and therefore use object equality for ===.


Why not "hello" === "hello"?
#17

Are ther eplans to fix this issue for v1.0?


#18

0.7:

julia> "hello" === "hello"
true

julia> struct T
           name::String
       end

julia> T("hello") == T("hello")
true

#19

To make sure I understand this correctly (I’ve already got confused by this issue in the past): the counter-intuitive T("Hello") != T("Hello") was fixed, but not by making == call the various fields recursively (meaning a == b iff a.f == b.f for every field). Instead what changed is that now the same string literals are ===?


#20

Yes.