# Why does \`==\` for custom types not compare field equality by default
**URL:** https://discourse.julialang.org/t/why-does-for-custom-types-not-compare-field-equality-by-default/91730
**Category:** New to Julia
**Tags:** isequal
**Created:** [December 16, 2022, 11:46am UTC](https://discourse.julialang.org/t/why-does-for-custom-types-not-compare-field-equality-by-default/91730 "2022-12-16T11:46:56Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@GoodDayToYouAll](https://discourse.julialang.org/u/GoodDayToYouAll)
#### Post date: [December 16, 2022, 11:46am UTC](https://discourse.julialang.org/t/why-does-for-custom-types-not-compare-field-equality-by-default/91730/1 "2022-12-16T11:46:57Z")
Hi everyone,
so this is less of a question _how_ this works, but more of _why_ it is implemented that way (I am trying to get into the Julia way of thinking and sometimes language designs seem counter intuitive).
So I know that `==` falls back to `===` so if I don’t overload `==` for my own type only truly identical objects (in the sense of `===`) are treated as equal.
Intuitively I would expect `==` to return `true` if it returns `true` for each field.
So the following behaviour seems weird to me:
```julia
struct X
x
end
julia> X([1]) == X([1])
false
```
I personally would expect the behaviour of `X` to follow the behaviour of its field, i.e.
```julia
julia> [1] == [1]
true
julia> [1] === [1]
false
```
So now I find myself going through my code and implementing this exact behaviour for all my types which is a bit tedious.
Why would anyone want this? Could anyone give me an example where my suggested default behaviour is not wanted?
Or I guess somewhere there might already be a discussion about this and I was just too stupid to find it. So I would also be grateful if someone could point me in the direction of the appropriate Git issue.
---
### Author:  [@melonedo](https://discourse.julialang.org/u/melonedo)
#### Post date: [December 16, 2022, 12:02pm UTC](https://discourse.julialang.org/t/why-does-for-custom-types-not-compare-field-equality-by-default/91730/2 "2022-12-16T12:02:57Z")
Not an answer, but if your types contain a lot of containers, you can try StaticArrays.jl. Immutable types do not differ in how they are compared by `==` or `===`.
---
### Author:  [@ranocha](https://discourse.julialang.org/u/ranocha)
#### Post date: [December 16, 2022, 1:05pm UTC](https://discourse.julialang.org/t/why-does-for-custom-types-not-compare-field-equality-by-default/91730/3 "2022-12-16T13:05:39Z")
I don’t have an answer of your original question (“Why is it implemented like this?”). But you may consider using [AutoHashEquals.jl](https://github.com/andrewcooke/AutoHashEquals.jl) to simplify the process of adapting it to your desired form.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [December 16, 2022, 6:52pm UTC](https://discourse.julialang.org/t/why-does-for-custom-types-not-compare-field-equality-by-default/91730/4 "2022-12-16T18:52:32Z")
Here’s the discussion: [== for immutables should recursively call == on its fields · Issue #4648 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/4648)
---
### Author:  [@GoodDayToYouAll](https://discourse.julialang.org/u/GoodDayToYouAll)
#### Post date: [December 19, 2022, 10:51am UTC](https://discourse.julialang.org/t/why-does-for-custom-types-not-compare-field-equality-by-default/91730/5 "2022-12-19T10:51:34Z")
Thanks, that is a great suggestion!
---
### Author:  [@GoodDayToYouAll](https://discourse.julialang.org/u/GoodDayToYouAll)
#### Post date: [December 19, 2022, 10:52am UTC](https://discourse.julialang.org/t/why-does-for-custom-types-not-compare-field-equality-by-default/91730/6 "2022-12-19T10:52:51Z")
Thank you very much,
this discussion partly goes over my head, but I see that it is a controversial topic. So let’s see whether there will be changes for 2.0