Support for 256bit integer types

[xermicus]

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 inpolkadot-js).

[jsdw]

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 paritytech/scale-value#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.

[ascjones]

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: paritytech/scale-info#25 (comment).

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

[jsdw]

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.

[ascjones]

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