Remove U64 and U128

[vorot93]

Obsoleted by u64 and u128 in Rust standard library.

[ordian]

My assumption is that these types are used to enforce some serialization format for RPC requests. Maybe this is easy to work around, but maybe there are also some use-cases I'm missing.

[niklasad1]

My assumption is that these types are used to enforce some serialization format for RPC requests. Maybe this is easy to work around, but maybe there are also some use-cases I'm missing.

Yes, these types exist because integer/unformatted data deserialization in ethereum is different because they are prefixed by 0x and won't work with the built-in types (u64/u128) in the Rust standard library without "glue code" (parsing hex strings doesn't work without removing the hex prefix in Rust, special handling of leading zeros and so on)

So, I see no point in removing them otherwise some other library or helpers has to do the same job. I guess it could make sense to use u64 and u128 internally if there is a performance benefit for it.

[sorpaas]

It's right now in Frontier for some borrowed code from OE, but I'm in favor of removing those -- should be easy to change them to the raw type.

[sorpaas]

My assumption is that these types are used to enforce some serialization format for RPC requests. Maybe this is easy to work around, but maybe there are also some use-cases I'm missing.

Yeah but I don't like that design to be honest. It's much better to define a type HexDisplay and use that for RPC return values.

[ordian]

My assumption is that these types are used to enforce some serialization format for RPC requests. Maybe this is easy to work around, but maybe there are also some use-cases I'm missing.

Yeah but I don't like that design to be honest. It's much better to define a type HexDisplay and use that for RPC return values.

Yeah, I don't mind removing them, but we should provide HexDisplay as a migration path. Not sure if it would fit primitive-types or ethereum-types though.

[ordian]

Planning to publish a few crates including uint 0.9 after #486 is merged.
As I mentioned I don't mind merging this PR as long as we provide a migration path (HexDisplay or whatever).

[vorot93]

@ordian My focus has switched from web3 JSONRPC to binary typed RPC protocols (like gRPC), so I have much less need and bandwidth to push this PR over the finish line. I suggest making a new release without it.