`GenericEqualityER` is broken for sets.

[sheganinans]

Repro steps

let n = nanf
let a = [|nanf|]
let l = [nanf]
let s = Set.singleton nanf
LanguagePrimitives.GenericEqualityER n n |> printfn "%b"
LanguagePrimitives.GenericEqualityER a a |> printfn "%b"
LanguagePrimitives.GenericEqualityER l l |> printfn "%b"
LanguagePrimitives.GenericEqualityER s s |> printfn "%b"

Expected behavior

true
true
true
true

Actual behavior

true
true
true
false

Known workarounds

None

Related information

Tested on:

• Win10 & Debian
• .Net 6 & 7

[T-Gro]

Thanks.
Set and Maps do not support the IStructuralEquatable interface, which is special cased for the " nan = nan " semantics by passing a custom comparer.
Seq is, so it should be possible to treat them the same way.

Thinking about Maps, I am not sure what the right approach would be to pass the nan semantics (nan = nan OR nan <> nan) when LanguagePrimitives.GenericEqualityER or LanguagePrimitives.GenericEquality is used:
Consider a Map<float,float>. Question is, where should the special nan-semantics apply:

• Apply to both keys and values
• Apply to values only
• (apply to keys only makes a little sense to me)

[sheganinans]

@T-Gro That explanation makes perfect sense. This issue isn't a huge blocker for me, it has just affected a few expecto properties, and I've been able to work around them.

I did a bit more testing on maps, and here is the result I got:

let m = Map.empty.Add(nan,"foo").Add(nan,"bar");;
val m: Map<float,string> = map [(nan, "bar")]

So it seems for my case, it would probably be safe if both keys and values had generic equality applied, since maps already act as such under the hood.

[T-Gro]

@T-Gro That explanation makes perfect sense. This issue isn't a huge blocker for me, it has just affected a few expecto properties, and I've been able to work around them.

I did a bit more testing on maps, and here is the result I got:

let m = Map.empty.Add(nan,"foo").Add(nan,"bar");;
val m: Map<float,string> = map [(nan, "bar")]

So it seems for my case, it would probably be safe if both keys and values had generic equality applied, since maps already act as such under the hood.

That makes sense, I did implement it like this => both keys and values ;; and covered the special Map<,> scenarios in new tests as well.

[sheganinans]

Sounds good! Thanks for the quick fix!