Digging a little deeper to understand this. Apparently, if my LLM is to be trusted, you need to index arrays with usize because they can be stored either on the stack or the heap and need to behave consistently across CPU architectures.
I didn't realize that arrays could go on the heap, but it seems this is what happens when you instantiate an array with Box, Vec, Rc, or Arc.
```
Box::new([1, 2, 3, 4, 5])
vec![1, 2, 3, 4, 5]
Rc::from([1, 2, 3, 4, 5])
Arc::from([1, 2, 3, 4, 5])
```
If only they could make the instantiation code more uniform...😅
Your new amount_to_index() function is a much better idea.
Basically all data types in Rust can go on either the array or the heap. There's some esoteric exceptions. But they're not important at your level of knowledge.
Rust was actually telling you something important with that apparently convoluted conversion: usize on many architectures is 32 bit. So you can't direct convert a u64 to a usize. You have to use a fallible conversion and deal with the potential error.
Also, Amount has a to_sats() method. So you could have used this instead:
usize.try_from(amount.to_sats()).unwrap_or(usize::MAX)
The rust-bitcoin library could also implement TryFrom to convert Amount into usize. But I suspect they won't as that's a really rare thing to do.
Thread collapsed
