fix(cast): consistent serialization of Uint/Ints depending on actual type

[0xferrous]

Motivation

The current implementation dynamically tries to determine if the runtime value can fit in 64 bits, but this leads to inconsistent serialization. For instance if you were decoding an uint[], some of the values that fit in 64 bits will serialize as number while others serialize as string making it require special handling on the user that is consuming the json.

Solution

Use the type information to determine the serialization. So the user will always know that specific types will always serialize to a number or a string depending on the number of bits that type uses.

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[0xferrous]

Okay this set out to be lot more complicated than I initially thought since the serialize_value_as_json function is integrated into cheatcodes and in turn affects all the serialize/parseJson and serialize/parseToml cheatcodes. I think I have found a lesser complicated solution by adding a parameter to determine if it is strict encoding which is set to true when called from cast and set to false when called from elsewhere to not alter any forge behavior.

Let me know if the proptest test is not enough for this and if you'd like to see any other/more kind of testing.

[0xferrous]

bumping here

[0xrusowsky]

hey @0xferrous, thanks for the PR!

you're right that this is an oversight in the current impl. To give some context: the original approach was designed to work around serde's number conversion limitations. It tries to preserve values as JSON numbers when they fit within 64 bits, since most uint256 values in practice are much smaller and using numbers provides better ergonomics.

however, as u've pointed out, this creates inconsistency for arrays where elements serialize
heterogeneously based on runtime values (which i previously overlooked).

since this primarily impacts arrays, i'd prefer a more targeted fix solely focused towards array serialization:

1. do a first pass through all elements to check if any require string
   representation
2. if all fit within 64 bits, serialize the entire array as numbers; otherwise serialize all values as strings

imo this is superior as it ensures type uniformity within each array while preserving ergonomics for simple values + i don't think we need the new flag u introduced... wdyt?

[0xferrous]

Just from the cast decoded output when json formatted, I dont think ergonomics matter much. this still means the serialization will differ with runtime values, the uniformity of serialization is better, yes, but since the decoding type is already provided by the user, they can know exactly what to expect depending on the type they provide.

Also, 2 ** 64 is a little over 18 eth, I don't think its that uncommon that values go beyond that especially when working with defi contracts.

[0xferrous]

Also for some personal context, I stumbled upon this because I was using the cast call --json commands chained together trying to read some data from the chain in nushell with cast call --json | from json where I assumed string and got a number type of thing or vice versa and I typed the function args certain way to cause the type error. although I think I might be able to get around that with some forced casting always, like always doing into string or into int.

[0xrusowsky]

@klkvr @DaniPopes thoughts?