Add an Iterators.copy() function

[GoogleCodeExporter]

Sometimes it is helpful to have the same iterator existing in two places.  It 
might be nice to have an Iterators.copy function.  For example, if I am writing 
an AbstractIterator that uses an iterator behind the scenes, and another 
function calls backingIterator.next(), then my abstract iterator is out-of-sync.

This function could be as simple as just calling 
ImmutableList.copyOf(iterator).iterator() - or it could be "smarter"

Original issue reported on code.google.com by nathan.t...@gmail.com on 20 Aug 2013 at 6:06

[GoogleCodeExporter]

I actually think the snippet you gave is perfectly readable:
ImmutableList.copyOf(iterator).iterator()

Original comment by kak@google.com on 20 Aug 2013 at 6:12

• Added labels: Package-Collect, Type-Addition

[GoogleCodeExporter]

Yeah, I think this is one of those things where it's pretty ambiguous what kind 
of Iterator you're getting (if the original supports remove(), would you expect 
a copy to somehow also support remove?) and what is actually happening if you 
just have an Iterators.copy method. Much better to just make it explicit that 
you're creating an immutable copy of elements of the Iterator by using 
ImmutableList.copyOf. Better still, of course, is to just have an Iterable that 
can give you two independent Iterators to begin with.

Original comment by cgdecker@google.com on 20 Aug 2013 at 6:18

[GoogleCodeExporter]

For the "smarter" implementation, I was going to refer to issue 524, comment 7, 
where I argue that a similarly smart Iterator is overkill. The simple 
implementation should work, of course, but the caller is going to need a 
two-parter, anyway: one line to create the multi-use object (probably an 
Iterable) and one line to call iterator() on it. By requiring two method calls, 
it's equally verbose to ImmutableList.copyOf(iterator) followed by iterator(). 
We'll stick with that.

Original comment by cpov...@google.com on 20 Aug 2013 at 6:25

• Changed state: WorkingAsIntended

[GoogleCodeExporter]

So - I am fine keeping this closed...but just as a side effect, if you do 
ImmutableList.copyOf(iterator).iterator(), then the original iterator gets 
completely consumed.  What would be helpful is a way to create an Iterable (or 
list, or itorator or anything) from an input iterator and have the two be 
independent of each other's "next()" calls.

Original comment by nathan.t...@gmail.com on 20 Aug 2013 at 8:44

[GoogleCodeExporter]

@nathan.toone: How would you possibly implement such a thing?  That's not 
possible.

Original comment by lowas...@google.com on 20 Aug 2013 at 8:51

[GoogleCodeExporter]

Very true :)  I guess that's why it doesn't exist then.

Thanks!

Original comment by nathan.t...@gmail.com on 20 Aug 2013 at 9:41

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:12

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit