Open xermicus opened 1 year ago
While TypeInfo can technically represent U256 and I256 types, I have generally been of the impression that they don't actually come up in practice. Maybe that's not true though when it comes to contracts; @ascjones I'd be interested to know what your thoughts are on this too?
If we added support for such types in Subxt, we should also add it properly in eg scale-value
, scale-decode
and such. See https://github.com/paritytech/scale-value/issues/8 for instance, and re scale-decode
, we currently just give back the raw bytes IIRC and it'd be nice to give back something nicer.
they don't actually come up in practice
Yes it's just for solang
contracts which has uint256
as a primitive.
Since scale-info
should mirror the parity-scale-codec
capability, I believe that the U256
primitive should be removed since there is no built-in impl. Similar sentiment from Robin: https://github.com/paritytech/scale-info/pull/25#issuecomment-713566862.
It would be different if parity-scale-codec
had a built-in U256
type and impl. For example there exists a U256
type in parity-common
and that just uses the TypeInfo
derive. https://github.com/paritytech/parity-common/blob/26c1423bacac3c248c45ea058cdee213d23adfb3/primitive-types/src/lib.rs#L41
Supporting the 256bit types is a bit of a pain in a couple of places (ie in scale-value they are the only types that can't be serialized and then deserialized again to the same output, because serde doesn't understand such types) and they currently can't be printed to strings and back (though that's easier to resolve but needs a proper u256/i256 type). In general, because they aren't rust primitive types I guess there will always be some pains like this.
So I'd be in favour of just removing them from scale-info
, and if 256bit types are used (like from primitive-types
), then in places like Subxt one can use type substitution (or from/into's) to make them ergonomic to work with.
So I'd be in favour of just removing them from scale-info, and if 256bit types are used (like from primitive-types), then in places like Subxt one can use type substitution (or from/into's) to make them ergonomic to work with.
I agree
Currently, subxt is missing support for integer types wider than 128bits. Smart contracts might use this type in their ABI, rendering subxt unable to interact with those contracts (they are supported in
polkadot-js
).