@devashishdxt seems this breaks on usize usage which is correct, as its size is platform-dependent.
The current uses were:

• not necessary: e.g. nonce probably shouldn't be usize
• something to do either with length or indexing into a vector: here, it'd need more thought. For example for transaction inputs/outputs, there's some implicit / configuration limit in Tendermint on block or transaction sizes anyway, so one can't enjoy the "full" u64::MAX/u32::MAX-size Vecs anyway (and the question is whether it could be any useful to have transactions with that many outputs/inputs). So, it could make sense to use ArrayVec instead, e.g. with a capacity u16::MAX and have all the usize places replaced with u16.

any thoughts?

So, it could make sense to use ArrayVec instead

@tomtau The only problem with ArrayVec is it allocates memory corresponding to its capacity even when there are very few elements in it. In most of our usecases, we'll have very few array elements, so, using ArrayVec is probably not a good choice. One option is change all the usages of usize to u64 and cast them to usize wherever necessary (bincode does this).

@devashishdxt

it allocates memory corresponding to its capacity even when there are very few elements in it

Depends on how much space that would waste. There's also a smallvec, so one could have a stack-allocated common case.
Anyway, there are two points in that example:

1. For some of these structures for TX, it may be good to have static "upper bound" (that's a way lower than u64::MAX) on the number of elements -- not only for the possibility of stack-allocation, but also for reasoning about memory requirements or block size: e.g. "if I have this much RAM or this maximum blocksize, it should able to hold at least this many TX in memory or contain them in a single block"

2. Depending on the upper bound, the length or index may not need to be held in u64.

For non-TX structures, e.g. Merkle tree length, it could be done as bincode does it.

For some of these structures for TX, it may be good to have static "upper bound" (that's a way lower than u64::MAX) on the number of elements -- not only for the possibility of stack-allocation, but also for reasoning about memory requirements or block size: e.g. "if I have this much RAM or this maximum blocksize, it should able to hold at least this many TX in memory or contain them in a single block"

Agree, but we don't have to use a different data structure to achieve this. SmallVec looks like a good optimisation but it won't solve usize problem.

Yeah, I guess the initial definitions could keep using Vec -- the allocation upper bound would be enforced be Decode implementation.

Just a note that parity-codec was renamed paritytech/parity-scale-codec@132e647 not on crates.io yet AFAIK

this PR is being resolved in #133

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.