Primitive streams and optional

[Tim Peierls]

On Tue, Nov 27, 2012 at 5:22 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> On Nov 26, 2012, at 10:12 PM, Sam Pullara <spullara at gmail.com> wrote:
> > I think I like 3 (or is this 4?) with additional methods that use
> suppliers for the cases where it isn't clear what we should do rather than
> Optional. Something like:
> >
> > T findFirst(Callable<T> notFound)
> >
> > Have we explored solutions like that? We could always override the
> method with one that has a well defined behavior in the miss case:
> >
> > T findFirst() // throws NoSuchElementException on failure
>
> I still prefer having one method that returns a "thing" that can be used,
> uniformly and in a fluent-like manner, to do determine whether a result is
> available or absent.
>

Me, too, if by "thing" you mean "Optional". It solves so many problems:
Strongly discourages use of null as a stream element, avoids user errors
stemming from the use of null as a sentinel value, makes code easier to
read, makes stream docs easier to read (by moving the available/absent
stuff elsewhere).

What are the drawbacks? Potential for overuse, as in Optional<Optional<T>>.
Creation of an intermediate object. Both drawbacks outweighed, imho, by the
benefits.

--tim