[WIP] elliptic-curve: use IntoIterator bound on LinearCombination

[tarcieri]

Allows passing any type which produces an iterator, rather than requiring all inputs are in a contiguous slice of memory

[daxpedda]

I explained in dalek-cryptography/curve25519-dalek#790 (comment) and dalek-cryptography/curve25519-dalek#790 (comment) why I believe this won't work and offered some, very poor imo, alternatives.

So the idea here is to do the following:

impl<'a, I: IntoIterator<Item = (&'a ProjectivePoint, &'a Scalar)>> LinearCombination<'a, I> for ProjectivePoint {
    // `Vec` implementation.
}

So how would the fixed array implementation look like?

impl<const N: usize> LinearCombination<'_, [(ProjectivePoint, Scalar); N]> for ProjectivePoint {
    // Fixed-array implementation.
}

This unfortunately would cause a conflicting trait implementation error.

However, what this change could facilitate is the following:

impl<K> LinearCombination<'_, HashMap<K, (ProjectivePoint, Scalar)>> for ProjectivePoint {
    // Internally uses `Vec` but support passing a `HashMap`.
}

Which I doubt is gonna be useful and it doesn't cover what curve25519-dalek is able to do right now.

[tarcieri]

Aah, okay, I see now, the existing trait is generic over any iterator, but has the drawback that it only works for allocating implementations since you can't size the temporaries array based on an iterator.

Whereas this bound is more general, but doesn't actually get you that generic-over-iterators functionality. Okay, seems like a fundamental tradeoff almost?

Since it borrows, you're right that it would only seem to be useful for supporting other heap-backed data structures where the data aren't contiguous. I'm not sure that's helpful or a worthwhile tradeoff for the additional lifetime bound. It would also require impls directly in the relevant elliptic curve crates, so the data structure would have to be supported in advance.

Going to close this then.