Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: implement Eq for Ipld #17

Merged
merged 1 commit into from
Mar 28, 2024
Merged

feat: implement Eq for Ipld #17

merged 1 commit into from
Mar 28, 2024

Conversation

vmx
Copy link
Member

@vmx vmx commented Mar 27, 2024

Implement the Eq trait for the Ipld enum. NaN floats are never equal to another. Though in the Ipld Data model they are forbidden. This means that we can implement Eq for it.

As it's currently not strictly enforced that an Ipld::Float does not contain a NaN, we make at least sure that in case we would encounter it, that it is treated as equal.

For more information about the dicussion about this topic, see ipld/libipld#171.

Implement the `Eq` trait for the `Ipld` enum. NaN floats are never equal
to another. Though in the Ipld Data model they are forbidden. This means
that we can implement `Eq` for it.

As it's currently not strictly enforced that an `Ipld::Float` does not
contain a NaN, we make at least sure that in case we would encounter it,
that it is treated as equal.

For more information about the dicussion about this topic, see
ipld/libipld#171.
@vmx vmx requested review from Stebalien and rvagg March 27, 2024 10:57
// NaN floats are forbidden in the IPLD Data Model, but still make sure they are treated as
// equal in case they accidentally end up there.
#[test]
fn test_partial_eq_nan() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens when you compare different nans? Try a 3-way comparison between f64::NAN with f64::from_ne_bytes([0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf0, 0x7f]) and f64::from_ne_bytes([0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f]), they're all going to be "equal" aren't they? How much do we care about such things? (Also one of the reasons that NaN is forbidden).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, it's okay to define these as equal. Especially given that we'll reject all these when we serialize and deserialize them.

Copy link
Contributor

@Stebalien Stebalien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks good to me, but I feel more comfortable if you could convince someone who didn't propose this, like @rvagg.

// NaN floats are forbidden in the IPLD Data Model, but still make sure they are treated as
// equal in case they accidentally end up there.
#[test]
fn test_partial_eq_nan() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, it's okay to define these as equal. Especially given that we'll reject all these when we serialize and deserialize them.

@rvagg
Copy link
Member

rvagg commented Mar 28, 2024

whatever, 🙈 🙉

@vmx vmx merged commit 456c831 into main Mar 28, 2024
12 checks passed
@vmx vmx deleted the impl-ipld-eq branch March 28, 2024 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants