How much value normalization will objecthash do?

[pedrocr]

I see from the code that unicode normalization is done. Is the idea also to do NaN normalization in floats? There are uses where this is not ideal and you don't want normalization at all. Will this be an option in the future? I'd actually argue the default case should be that otherwise it's easy to generate matching hashes for objects that will then behave differently when passed to certain functions.

[tarcieri]

All other objecthash implementations make Unicode normalization a configurable toggle. The present ObjectHasher API does not carry around the context to provide such toggles, although it could.

I will go ahead and leave this issue open to discuss whether such a toggle should be added.

That said, there are two places objecthash performs the sort of normalization you might see in a canonicalization scheme:

• Unicode normalization
• Sorting object keys by their objecthashes

[pedrocr]

And how about float, any plan for that?

[tarcieri]

@pedrocr personally I hate floating points, and the nascent objecthash-inspired scheme I have been working on does not support them at all.

That said, NaN (along with Infinity) is not part of the JSON data model, and IMO is best avoided. Attempting to serialize those (or hash them) should be an error.

[pedrocr]

Ok, between this and the performance penalty of all those text conversions I'll have to roll my own then. Supporting float is essential and NaN's are just part of the data. serde->bincode->Sha256 seems to be working well but I may take a stab at just implementing some form of #[derive(CryptoHash)].

[tarcieri]

Note the scheme I'm working on avoids the text conversion

[pedrocr]

If it doesn't do floats it's a no-go for me. Good image processing is all about f32. I'd have to do a bunch of manual conversions to/from fixed-point or something of the sort and that just makes for extremely ugly code.