`compute_hash_on_elements` could accept any iterator on `FieldElement`

[tdelabro]

https://github.com/xJonathanLEI/starknet-rs/blob/d980869d44ef86249b4077f4ec809165f470678d/starknet-core/src/crypto.rs#L49

Right now the signature requires the input to be &[FieldElement] but it's implementation would still be valid if the input were to be a more generic T: Iter<FieldElement>. It would allow more flexibility for the lib users

[xJonathanLEI]

The issue with Iterator<FieldElement> is then you can't use say slices they yield &FieldElement instead of FieldELement.

[xJonathanLEI]

What we could do is maybe T: AsRef<[FieldElement]>? This way you can send in anything that can be referenced as a slice, but then... if you can reference it as a slice you could have just passed in the slice like you do right now.

The only benefit of this change, as far as I know, is that you can now also pass in owned values, which could be useful in a threading scenario. Not that it's not useful in certain cases, but it's probably not what you're looking for.

[xJonathanLEI]

Oh the other hand, we can indeed provide a hasher type which would actually work better with iterators? Such a hasher would probably be rather generic and won't hash the arrary length at the end though.

[tdelabro]

https://rust-lang.github.io/api-guidelines/flexibility.html#functions-minimize-assumptions-about-parameters-by-using-generics-c-generic

T: IntoIterator<Item = FieldElement> requires you to have ownership of the value, if you want to pass a slice, you can do so:

compute_hash_on_elements(my_slice.into_iter().cloned())

This ensures you own the value you are passing in.