the decimal string and json number representations are off-spec for the vast majority of RPC types. Essentially all integers in eth json rpc are represented as Quantity, which is a minimal-nibble 0x-prefixed hex string. Ethereum nodes will always reject decimal string and json number representations for those types. there are a few random types that do permit json number for floats but they're uncommon
ruint as a separate project aims to support deser of all of decimal string, hex string, binary, and json numeric. and uses Quantity encoding for serialization only for human readable serializations
this means that alloy, where it uses U*** types will tolerantly deserialize invalid eth RPC objects. by switching to u64/128_hex_or_decimal we're actually narrowing the allowed inputs a lot while moving closer to eth RPC spec conformance. and u64/128_hex is the closest we'll come to actual spec conformance (Quantity is technical unbounded size integer but we ain't supporting that junk)
so while i don't particularly value spec conformance, we have no use case for tolerant deser, and we need a consistent policy for these so we don't keep having type divergence based on who is writing the code
which leads me to like u64/128_hex as the "obvious" choice. if we enforce the specified encoding nobody is making tolerance decisions on the fly, and therefore we end up with more consistent code
Originally posted by @prestwich in #454 (comment)
the decimal string and json number representations are off-spec for the vast majority of RPC types. Essentially all integers in eth json rpc are represented as Quantity, which is a minimal-nibble 0x-prefixed hex string. Ethereum nodes will always reject decimal string and json number representations for those types. there are a few random types that do permit json number for floats but they're uncommon
ruint as a separate project aims to support deser of all of decimal string, hex string, binary, and json numeric. and uses Quantity encoding for serialization only for human readable serializations
this means that alloy, where it uses U*** types will tolerantly deserialize invalid eth RPC objects. by switching to u64/128_hex_or_decimal we're actually narrowing the allowed inputs a lot while moving closer to eth RPC spec conformance. and u64/128_hex is the closest we'll come to actual spec conformance (Quantity is technical unbounded size integer but we ain't supporting that junk)
so while i don't particularly value spec conformance, we have no use case for tolerant deser, and we need a consistent policy for these so we don't keep having type divergence based on who is writing the code
which leads me to like u64/128_hex as the "obvious" choice. if we enforce the specified encoding nobody is making tolerance decisions on the fly, and therefore we end up with more consistent code
Originally posted by @prestwich in #454 (comment)