Add support for i128 / u128 #6
Conversation
There was a problem hiding this comment.
I think I would not want to do 2.x over this.
If there is a more fully featured serde testing library that people use in the meantime, that is all right with me. Serde_test is not special outside of being the crate that serde's test suite has used. But there is not a particular ecosystem value to everybody sticking to the same library as serde's test suite.
Some other things that should be evaluated for a 2.x:
- Order-insensitive comparison, such as being able to test data structures containing HashMap/HashSet, which is not possible today.
- Do
skip_fieldcalls need to be represented. - Is human_readable integrated in the right way. This is something that was tacked on substantially later than 1.0.
- Examine all the current users of serde_test on crates.io and any lessons learned from that usage.
- Any relevant open issues on the serde repo.
|
This support is just needed in order to make some comprehensive tests in serde test_suite. Right now I have to avoid testing support for 128-bit integer, which, given that it is supported in serde only partially, makes it much more difficult to identify places where it is absent and what can affect
That's really needed to do at once in one release? It seems to me that it is enough to include that features that's ready, in order of their readiness |
|
Because since serde-rs/serde#2600 the 128-bit integers are not gated anymore it would be useful to test they support and |
Mingun
force-pushed
the
integer128
branch
3 times, most recently
from
3b647e6
to
d59aef8
Compare
Because MSRV is 1.56 which has support of 128-bit integers, serde_if_integer128 hack is not needed
Because MSRV is 1.56 which has support of 128-bit integers,
serde_if_integer128hack is not needed.This is breaking change because
Tokenenum is not marked asnon_exhaustiveand it is changed.Closes #18