Open freemin7 opened 1 year ago
I don't see the issue. There are two different arrays (in the car
field), and they are not ===
, so they are distinctly different flower
structs with different ==
and hash
. That seems to be what you are seeing too, as I would expect
@freemin7 To expand on this a little, your issue is equivalent to this:
julia> struct Foo
x::Vector{Int}
end
julia> Foo([1]) == Foo([1])
false
This happens because ==
is not explicitly defined for Foo
, so it falls back to the following fallback definition
==(x, y) = x === y
And since the two inner arrays are not ===
to each other, the result is false
.
The ===
fallback is unfortunate. Issues https://github.com/JuliaLang/julia/issues/4648 and #40717 propose alternative (and IMO, better) solutions, but changing the default fallback is breaking, so it will probably never happen.
Well it's not what i expected. I thought i tested that case with.
@assert lettuce.car == eval( Meta.parse( string(flower(uidv, uid)))).car ## passes
It is extremely surprising behavior that
@assert ( Foo([1]).x == Foo([1]).x ) && not(Foo([1]) == Foo([1]))
And the documentation while truthful is only truthful by omission. When i work with UUIDs and serialization i think "someone might have messed up the interning" https://en.wikipedia.org/wiki/Interning_(computer_science) of UUIDs and while i read "Falls back to ===." in ?==
that wasn't strong enough language to consider that it a sensible default wasn't chosen for structs. The "For example," makes the listing of exception to the fallback incomplete. "structs being a direct sub-type of Any use the fallback by default." would have been sufficiently explicit to grab my attention.
Another alternative would be a referencing a struct_equal https://github.com/JuliaLang/julia/issues/4648#issuecomment-1093896734 in a see also section if something like that existed in stdlib. Does something like that exist in Base already?
Either way the issue could be closed by a more explicit documentation.
installed via JuliaUp
Context: I discovered this problem using JSON3 where deserialisation/serialisation identities failed however could reproduce the issue in without those packages loaded. The same holds for
uuid1
. This is extremely cursed.Some more testing yielded that: