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
add Iterator#dropInPlace #65
Comments
The semantics of Would it be possible to refine the return type of |
is this not mutating the iterator, which is a collection(-ish)? |
True, but the way I see it is that an Nevertheless, I still think that what we really want in the long-term is to fix the signature of |
Currently the rule for all methods except |
I like Julien's suggestion, and I'm okay with having specific exceptions to the rule/tweaking the rule |
Then IMO it would be better to add a method with a name that stands out more, like Are we even sure that |
it's not equivalent; it has the same contract as |
.drop(...)
is equivalent to calling.next()
(up to) a given number of times, which is very useful. unfortunately,.drop(...)
is not required to return the same instance (though the default implementation does), which means you need to assign it to a freshval
. Having to create a second binding for the iterator is ugly, and potentially error prone if you accidentally keep using the oldIterator
instance..dropInPlace(...)
would be guaranteed to returnthis.type
, allowing you to keep a singleval
/binding.The text was updated successfully, but these errors were encountered: