Add std::num::Wrapping impl #1072
Conversation
UserAB1236872
changed the title
| { | ||
| Deserialize::deserialize(deserializer).map(Wrapping) | ||
| } | ||
| } |
| fn deserialize<D>(deserializer: D) -> Result<Wrapping<T>, D::Error> | ||
| where D: Deserializer<'de> | ||
| { | ||
| Deserialize::deserialize(deserializer).map(Wrapping) |
There was a problem hiding this comment.
Deserializing a Wapping<u8> from 500 will fail. Does that match your use case?
There was a problem hiding this comment.
Can you clarify? Do you mean that if you deserialize a number that exceeds the max for that type it won't wrap? That's fine, I didn't expect it to use the wrapping functionality at deserialization time.
There was a problem hiding this comment.
Then isn't this something Wrapping(u8::deserialize(deserializer)?) can already accomplish without this impl?
There was a problem hiding this comment.
Yea that's what I meant. Just wanted to make sure. It's backwards compatible to change later if we want to.
There was a problem hiding this comment.
@hcpl If you just want to (de)serialize a Wrapping that's fine, but it becomes somewhat more problematic if you want to Derive a struct containing one. I guess you could decorate every field with a wrapping with a with attribute, but it's overall cleaner to do this.
There was a problem hiding this comment.
So there are 2 desired behaviours for Wrapping: accept and produce values in the certain range, or only do so for producing values while accepting anything.
Logically speaking, if we were to provide wrapping behaviour in impl Deserialize, we would have to do custom number parsing to wrap any possible number for consistency's sake.
Also, Wrapping<T> doesn't have any bounds on T, which means we end up having to rely on the unstable specialization feature for numeric types.
So yeah, easier to leave things this way.
| { | ||
| self.0.serialize(serializer) | ||
| } | ||
| } |
|
Should I fix the newlines in a new commit, or do an amend? |
|
I pushed a commit fixing the newlines, if you'd prefer it to be squashed I can do that too. |
fine with me |
|
I added some unit tests in 9b08915 and released this in Serde 1.0.17. |
Addresses #1020
This would really help with cutting down the code bloat in:
rust-random/rand#189
By making more of the structs
deriveable. We'd still be blocked waiting for blanket impls that are generic over array/tuple size constants for two of the RNGs, but this would help with a lot of code.Unfortunately, since
Wrappingis instd, there's no way to do this cleanly without directly modifyingserdeor manually implementing for/working around every type that uses aWrappingforever. This is an extremely small change.