-
Notifications
You must be signed in to change notification settings - Fork 430
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimise IteratorRandom::choose
for size_hint
or ExactSizeIterator
#511
Comments
Opinions on what we should do if So for example, a simple implementation strategy would be to check if |
To quote the doc:
Beyond that there's not much guidance; i.e. I think it should be acceptable to return "incorrect" results if |
There’s an exception for |
Yes, but does "may return whatever" mean:
|
There are no restrictions to So, while, there is a side-effect to using For Given a deterministic backing random number generator (
|
Ultimately, however, it is up to you to decide what the semantics are when |
If we have the above requirement I don't see that we could take advantage of But we can always wait until specialization stabilizes and use |
I suppose those constraints are necessary to avoid a change in The alternative is just to point out that the implementation of |
I agree that pointing out that Likewise to point out that If there's agreement that that's ok, then I'm happy to write up a PR? |
I don't think it needs to panic, but I think it's acceptable to introduce bias in the output (i.e. select some element as a fallback in case the iterator is not as long as Perhaps though we should bring this up elsewhere to get more opinions. I don't really know where people might write incorrect |
@sicking the answer seems to be that we're allowed to break things if |
IteratorRandom::choose
uses one random number per item since it has no way of knowing how many items will follow.We do not use
size_hint
since it is not guaranteed that the supplied bounds are correct; though since incorrect implementations are considered buggy we could try.Alternatively
ExactSizeIterator
could be used, but probably not without specialisation.The text was updated successfully, but these errors were encountered: