owned::Value and borrowed::Value don't implement std::cmp::Eq

[bassmanitram]

My continuing attempts to get simd_json "dropped in" as a replacement for serde_json (with some inevitable mutability hacks of course) are stymied at the moment because, while serde::Value implements std::cmp::Eq, the simd_json equivalents do not. Is there a reason for this, or is it simply and oversight?

[Licenser]

This concerns floats (the bane of everyone's existence). Floats notoriously do not offer EQ since numbers that should be equal don't always turn out equal but might end up in a tolerance. On the other hand, numbers in that tolerance might not be equal.

[bassmanitram]

Well yes that would explain it... But, then again, what does serde_json do to 'get away with it' that simd_json couldn't do (somewhat rhetorical since, if you don't know, I'll look into it)

…

On Sat, Oct 19, 2024, 19:38 Heinz N. Gies ***@***.***> wrote: This concerns floats (the bane of everyone's existence). Floats notoriously do not offer EQ since numbers that should be equal don't always turn out equal but might end up in a tolerance. On the other hand, numbers in that tolerance might not be equal. — Reply to this email directly, view it on GitHub <#398 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAKLWRFE72YM3GJLNN26FDZ4KKKDAVCNFSM6AAAAABQHVJEU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRUGEYDGMZZGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bassmanitram]

And there it is - in serde_json Numbers are stored as strings until they are used via "is_xx" and "and_xx" - so Value CAN be Eq. This actually seems to me to be very sensible, since, when encapsulated by Value we are looking at "JSON" values which are always strings. They only become "float" when the caller says "can you be a float, if so gimme a float".

Looking at the simd_approach, that doesn't work - you assume that the user wants the float when you create the Value rather than when the Value is actually "unwrapped". So your comment above is correct - floats can't be strictly Eq. Unfortunately that's a significant blocker to having simd_json be a "fairly easy" droppin replacement for serde_json.

I'm guessing that modifying the approach to Number storage is a no-go ... what about a feature "serde_json" that changes how OwnedValue is implemented ... oh... or a third "type" of Value ... one that is compatible with serde_json (I could work on either of those, just don't want to "waste my time" if you guys don't think it's feasible or desirable).

[bassmanitram]

OR ... could we store the string value with the float value in order to handle the "equivalence" constraint?

[bassmanitram]

OR ... https://crates.io/crates/ordered-float (which implies a change to value-trait)

[Kriskras99]

If you just want Eq, you could also just use the f32::total_cmp function (stable since Rust 1.62.0).
The issue I see, is that multiple string representations can give the same float which means Eq would say two fields are equal while they aren't.
Maybe add a feature flag for Eq, so people can opt-in/out

[Licenser]

Ja strings are not a great option but @bassmanitram's PR for value-trait looks like a really good way to get the best of everything without the need to compromise.

[Licenser]

released as 0.14.2 thanks @bassmanitram !!!