Fix multiple TODOs#89
Conversation
There was a problem hiding this comment.
Few questions and nits mostly :-)
Also could you make it to merge into https://github.com/paritytech/bls/tree/skalman/fix-audit-findings instead of master please?
| type M = Message; | ||
| type PKG = PublicKey<E>; | ||
|
|
||
| type PKnM = ::core::iter::Once<(Message, PublicKey<E>)>; |
There was a problem hiding this comment.
Could you explain me that how is replacing Once with ExactSizeIterator works?
There was a problem hiding this comment.
PKnM is removed from the trait definition and as the bound there was PKnM: Iterator<Item = (Self::M, Self::PKG)> + ExactSizeIterator we can use this bound as return type for messages_and_publickeys, while the actual return type will stay ::core::iter::Once<(Message, PublicKey<E>)> which implements both Iterator and ExactSizeIterator
|
|
||
| type M = &'a Message; | ||
| type PKG = &'a PublicKey<Self::E>; | ||
| type PKnM = ::std::collections::hash_map::Iter<'a, Message, PublicKey<E>>; |
There was a problem hiding this comment.
I believe the explicit use of hash_map was intentional to impose the hash_map's orders, do we know for sure if we remove the hash_map we get the same ordering?
There was a problem hiding this comment.
The type of the value returned from messages_and_publickeys will stay the same (it just won't be explicitly stated in the associated type), so the iteration order will stay the same
2 participants
Part of #88
Resolves #87
Benchmarks have shown that batching curve normalizations in
verifywon't give any significant performance gains (a difference was less than 1% in my tests)