Add `Itera[tor|ble]s.findOptional`

[GoogleCodeExporter]

With the arrival of `Optional`, we've got a very appealing alternative to 
getting back `null` as well as a `NoSuchElementException` being thrown if no 
matching element was found. Thus, I suggest adding a find method that returns 
an optional.

Implementation for `Iterators`:

  public static <T> Optional<T> find(Iterator<T> iterator, Predicate<? super T> predicate) {
    UnmodifiableIterator<T> filteredIterator = filter(iterator, predicate);
    return filteredIterator.hasNext()
      ? Optional.of(filteredIterator.next())
      : Optional.absent();
  }

Original issue reported on code.google.com by j...@nwsnet.de on 19 Aug 2011 at 2:21

[GoogleCodeExporter]

Have thought about just this.  A catch is that it will blow up if the iterator 
contains null and the predicate matches that null, but that seems unlikely to 
happen.

Original comment by kevin...@gmail.com on 20 Aug 2011 at 7:11

• Changed state: Triaged
• Added labels: Type-Enhancement

[GoogleCodeExporter]

Wouldn't that require a predicate that accepts `null` in the first place? 
Haven't yet come up with a use case for that (for which no - maybe even better 
- alternative exists). After all, it seems to me like a hypothetical situation 
that's by far outweighed by the usefulness of the method requested here.

In other news:

- Is `Holder` going to be released as well? The current, far less appealing 
approach to push a value from an anonymous method to the enclosing scope 
(besides the return value) is to have a one-element array and store the value 
there (as suggested by IntelliJ IDEA).

- Can't wait for the new stuff. See this as a motivational nudge to get r10 out 
the door rather sooner then later :)

Original comment by j...@nwsnet.de on 24 Aug 2011 at 1:04

[GoogleCodeExporter]

FYI, Holder won't make it into the next release...we're still evaluating the 
usefulness of it. Note you can also use an AtomicReference to "push a value 
from an anonymous method to the enclosing scope".

Original comment by kurt.kluever on 24 Aug 2011 at 7:08

[GoogleCodeExporter]

Thanks for the hint!

Regarding `Holder` I think it is very useful, but only for a very limited 
number of cases I currently know. So leaving it out wouldn't be too bad.

Original comment by j...@nwsnet.de on 25 Aug 2011 at 8:10

[GoogleCodeExporter]

I think Optional versions of some Itera*s methods, including this one, *could* 
be a good idea... but what would we call them now that we already took the good 
names?  findOptional(), findIfPresent()... blech.

Original comment by kevinb@google.com on 29 Aug 2011 at 6:14

[GoogleCodeExporter]

I'm sure those additional methods returning `Optional` *are* a good idea.

Basically, I'd prefer the original methods to be retrofitted to use `Optional`, 
but that's not an option (sad pun) at this stage of the API. So yes, in that 
case, the good names are taken.

But as long as the additional methods have a common prefix/infix/suffix 
("Optional" is clear, "Opt" is short, "tryTo..." is quite cumbersome at not 
unique enough), a few characters more are still far better than working around 
stuff everytime:

`Optional.fromNull(Iterables.find(items, predicate, null))`
vs. 
`Iterables.findOpt(items, predicate)`

E. g., `getLastOpt` would be ok for me.

Original comment by j...@nwsnet.de on 30 Aug 2011 at 12:14

[GoogleCodeExporter]

I wonder if after adding findOptional we could actually deprecate the other two 
find methods. Then the net effect on surface area would be to shrink it, which 
is great... but it still doesn't let us use the good method name unless we then 
go through *another* deprecation round <ugh>.

Original comment by kevin...@gmail.com on 1 Sep 2011 at 5:24

[GoogleCodeExporter]

Yeah. But nobody said API design would be easy ;)

If migrating `find` to eventually returning `Optional` is be strongly 
considered the right thing to do, then I see plenty of time to do it between 
r09 and 1.0.

Original comment by j...@nwsnet.de on 1 Sep 2011 at 6:56

[GoogleCodeExporter]

Between release 9 and ... what? :) We're up to release 10 aka 10.0 (next month).

Original comment by kevinb@google.com on 1 Sep 2011 at 11:28

[GoogleCodeExporter]

Oh, ok then. I was assuming the release numbers would indicate pre-releases or 
something like that because I'm not used to that notation (as opposed to, say, 
9.0 or v9).

Original comment by j...@nwsnet.de on 2 Sep 2011 at 11:03

[GoogleCodeExporter]

You and 99% of the world.  It was foolish of me to think there was no point in 
adding the ".0" explicitly :-)

Original comment by kevin...@gmail.com on 3 Sep 2011 at 4:08

[GoogleCodeExporter]

Original comment by fry@google.com on 10 Dec 2011 at 4:15

• Added labels: Package-Collect

[GoogleCodeExporter]

I observe that this is done with the arrival of Itera(tors,bles).tryFind in 
release 11.

Original comment by wasserman.louis on 25 Dec 2011 at 4:41

• Changed state: Fixed
• Added labels: Milestone-Release11

[GoogleCodeExporter]

Excellent, thanks!

Original comment by j...@nwsnet.de on 2 Jan 2012 at 10:41

[GoogleCodeExporter]

This issue has been migrated to GitHub.

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

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

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

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

• Added labels: Restrict-AddIssueComment-Commit