Solidity <> JS primitive types

[holic]

I don't have a particular proposal, but would like to start a discussion around how best to translate Solidity types into JS and back. Some questions I have:

• For Solidity ints/uints, what should the "cut off" be between JS number and bigint? Number.MAX_SAFE_INTEGER is 2^52, which means up to int48 and uint48 could fit in it, but would it make it tricky to use because it can overflow if you add two large values together? Should everything be a bigint? Should number just be for int32 and uint32 to more closely match traditional databases?
• For Solidity bytes types (including bytes1-bytes32), should the JS representation be Uint8Array, because it's the closest native JS type to a "buffer"? @0xOlias was saying Uint8Array is a little clunky to use and hoping he can fill in his experience. Maybe hex strings make the most sense, with utils to move between hex string and Uint8Array, because strings are easy to log, json encode, etc.? Probably not worth inventing our own type, otherwise we end up in the same situation as ethers and juggling BigNumbers.

[tmm]

Do you mean at runtime, type-level, or both?

[holic]

Both!

For MUD, we're working on a way to define schemas that result in generating code in Solidity and TS to write data in a structured, efficient, packed form (i.e. using our own encoding/decoding). As such, we need a mapping between Solidity types and TS types and back, where the boundaries of each type exist, etc.

It makes the most sense to me if these types align well with viem, etc. so things Just Work.

[jxom]

atm:

• address -> "0x${string}"
• bool -> boolean
• string -> string
• tuple -> Object (if all named params), Array (otherwise)
• u?int8-48 -> number
• uint & uint56-256 -> bigint
• bytes -> "0x${string}"

thought about bytes being a Uint8Array, but I don't see any benefits (apart from type symmetry) as it'll make encoding/decoding abis a lot more tedious from a DX perspective (as you'd need to do unnecessary intermediary encoding) and will slow down performance a fair bit. feel like hex is so much easier to work with.

example encoding/decoding multicall data (green diff is if bytes were Uint8Arrays):

// prepare data for multicall calls
const calldata = encodeFunctionData(...)

// prepare multicall data
-const multicallData = encodeFunctionData({ ..., args: [calldata] })
+const multicallData = encodeFunctionData({ ..., args: [toBytes(calldata)] })

// call multicall contract
const data = await call({ ..., data: multicallData })

// decode multicall result
-const [multicallResult] = decodeFunctionResult({ ..., data })
+const [multicallResult] = decodeFunctionResult({ ..., data: toBytes(data) })

// decode result from multicall
const { returnData, success } = multicallResult
const result = decodeFunctionResult({ ..., data: returnData })

[holic]

That all makes sense. What about methods like keccak256 where it currently accepts a Uint8Array?

[jxom]

Yeah, good call. Probably makes sense for keccak256 to accept a hex representation of data too. Fixed!