Improve Filter API

[rustaceanrob]

There is a bit of trait hell going on within the bip158 module. Something in the BlockFilter type is generic over Read, but the type itself concretely uses Vec. The Read implementation of Vec doesn't do any I/O so the result is infallible. We can just add an expect instead of propagating this error everywhere.

ref: Use of Vec followed by the trait hell

cc @nyonson

[rustaceanrob]

While I was at it, I changed the API signature of match_any to be more generic. All the collections implement Iterator, so limiting to HashSet is more of an internal implementation detail. I caught the impl bug in method signatures over the past couple months.

[nyonson]

There is a bit of trait hell going on within the bip158 module. Something in the BlockFilter type is generic over Read, but the type itself concretely uses Vec. The Read implementation of Vec doesn't do any I/O so the result is infallible. We can just add an expect instead of propagating this error everywhere.

ref: Use of Vec followed by the trait hell

cc @nyonson

Hm, the links you provided are the same? Not sure if intended cause I don't see the Read trait usage. But in any case, is the idea that there will definitely not be I/O errors since no I/O is actually happening?

[rustaceanrob]

Oops, here is the line showing the Vec. Yeah, for this particular use case, the in-memory readers will be infallible since the size of the data is known and there's no I/O

[nyonson]

Feels a little bad ignoring the API, but yea, makes sense.

[nyonson]

ACK 081b38c

[rustaceanrob]

Yeah... the impl Iterator method signature might be the better of the improvements here. Tomorrow I may just update to change the method signature and do away with the expect?

I take a lot of pride in the lack of panic conditions, even though this one should never trigger. It is a tiny amount of insurance to any changes to std::io::Result as well.

[rustaceanrob]

self-ACK 87a9403