You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not clear that keeping track of the exact size of an iterator is super useful, and it has a definite cost: it may be surprising that my_bitmap.iter().next() (creating an iterator, and visiting only the first value) will visit every container in the bitmap to compute the size_hint field for the iterator (which is never used).
We could either:
Lazily (but exactly) compute the actual remaining size in size_hint: this means the price is only paid when size_hint() is actually called.
Lazily inexactly compute a minimal/maximal remaining size (whatever we can compute in O(1)). This would be a breaking change: currently Iter implements ExactSizeIterator (on 64 bit platforms). However I believe that's more in line with the expectation of what size_hint() is expected to act like.
I think I lean toward option 1 (probably not worth a breaking change to do 2, and it's O(n), but with a tiny per-container cost, so still expected to be fast). What do you think @Kerollmops?
The text was updated successfully, but these errors were encountered:
See some discussions under #290 (review)
It's not clear that keeping track of the exact size of an iterator is super useful, and it has a definite cost: it may be surprising that
my_bitmap.iter().next()
(creating an iterator, and visiting only the first value) will visit every container in the bitmap to compute the size_hint field for the iterator (which is never used).We could either:
size_hint
: this means the price is only paid whensize_hint()
is actually called.O(1)
). This would be a breaking change: currentlyIter
implementsExactSizeIterator
(on 64 bit platforms). However I believe that's more in line with the expectation of whatsize_hint()
is expected to act like.I think I lean toward option 1 (probably not worth a breaking change to do 2, and it's
O(n)
, but with a tiny per-container cost, so still expected to be fast). What do you think @Kerollmops?The text was updated successfully, but these errors were encountered: