<div dir="ltr"><div style><span style="font-family:arial,sans-serif;font-size:13px">I&#39;m OK with these two forms.</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style>
<span style="font-family:arial,sans-serif;font-size:13px">I would use findFirst() if I wanted to throw an exception if empty -- or execute an &#39;else&#39; clause.</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">I would use findFirstOrElse(ifEmpty) if I wanted to substitute a different value.</span></div><span style="font-family:arial,sans-serif;font-size:13px"><div>
<br></div></span></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 15, 2013 at 12:06 PM, Brian Goetz <span dir="ltr">&lt;<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Even ignoring infinite streams, it would still perform poorly on large streams if generating the stream elements (or the upstream operations) have any cost whatsoever.<br>

<br>
The short-circuiting ops (find, matchXxx, and limit) force traversal to use tryAdvance instead of forEach, to be more responsive.<br>
<br>
There really are two orthogonal considerations with find:<br>
<br>
 - Should find() take a predicate, or not?<br>
 - How do we specify what to return if you find nothing?<br>
<br>
It seems to me that people gravitate towards the predicate version because of the name &quot;find&quot;, but if it were just called &quot;first&quot;, they might feel differently.  In any case, I find the predicate version a distraction:<br>

 - You can always specify a predicate using an upstream filter(), which is not that much less efficient, just one more pipeline stage. Specifying the predicate in find is just a fusing optimization, and not one that saves a lot of extra work.<br>

 - For people who just want the first, having to specify a &quot;no-op&quot; predicate is annoying.  Which pushes us back to two versions, a predicate-version and a predicate-less version -- and I don&#39;t think the predicate version carries its weight.  However, maybe the name is just wrong.<br>

<br>
The second is the Optional vs default.  We&#39;re not revisiting the &quot;whither Optional&quot; discussion here; what we&#39;re discussing here is whether it is better to have both, for both findXxx and various reduce.<br>

<br>
  Optional&lt;T&gt; findFirst()<br>
  T findFirstOrElse(T sentinal)<br>
<br>
The argument in favor of both is that the latter is more efficient, without running into the &quot;null might mean nothing or might mean that the first element was null&quot; problem.  Though I suspect a lot of people would use null as the sentinel and then shoot themselves in the foot anyway.<div class="im">
<br>
<br>
<br>
<br>
<br>
On 3/15/2013 2:56 PM, Joe Bowbeer wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
It wasn&#39;t obvious to me until recently that it is the short-circuiting<br>
behavior of the &#39;find&#39; methods that is hardest to derive.<br>
<br>
Without short-circuiting, findFirst forms could be derived as follows,<br>
but they will fail on infinite streams:<br>
<br>
T findFirst(T ifNone) {<br>
   return reduce(ifNone, (l, r) -&gt; (l != ifNone) ? l : r);<br>
}<br>
<br>
T findFirst(Predicate&lt;? super T&gt; predicate, T ifNone) {<br>
   return reduce(ifNone, (l, r) -&gt; (l != ifNone || !predicate.test(r)) ?<br>
l : r);<br>
}<br>
<br>
I&#39;m not sure why, but I&#39;m liking the idea of only adding<br>
findAny(predicate, ifNone).<br>
<br>
--Joe<br>
<br>
<br>
On Fri, Mar 15, 2013 at 8:04 AM, Doug Lea &lt;<a href="mailto:dl@cs.oswego.edu" target="_blank">dl@cs.oswego.edu</a><br></div><div><div class="h5">
&lt;mailto:<a href="mailto:dl@cs.oswego.edu" target="_blank">dl@cs.oswego.edu</a>&gt;&gt; wrote:<br>
<br>
    On 03/15/13 09:46, Brian Goetz wrote:<br>
<br>
        Wouldn&#39;t the minimal change NOT have a predicate, to match the<br>
        existing form of<br>
        findFirst?<br>
<br>
            Optional&lt;T&gt; findFirst()<br>
            T findFirst(T orElse)<br>
<br>
<br>
    Yes and no. The only way to get non-optional-bearing<br>
    result for search would otherwise be s.filter(pred).findAny(),<br>
    which entails buffering of stuff you will throw away.<br>
<br>
    This is also the reason only adding why findAny(pred) (not findDirst)<br>
    is defensible: the alternative is of most interest to the sort of<br>
    person who want to avoid that Optional too.<br>
<br>
    -Doug<br>
<br>
<br>
<br>
<br>
<br>
        On 3/15/2013 7:31 AM, Doug Lea wrote:<br>
<br>
            On 03/15/13 06:26, Joe Bowbeer wrote:<br>
<br>
                Doug,<br>
<br>
                I think your point that Optional and non-Optional forms<br>
                of reduce are<br>
                already<br>
                provided is significant.<br>
<br>
                I noticed that your proposed versions of findFirst and<br>
                findAny have a<br>
                Predicate<br>
                argument, but the Optional forms do not:<br>
<br>
                T findFirst(Predicate&lt;? super T&gt; predicate, T ifNone);<br>
<br>
                Why is this?<br>
<br>
<br>
<br>
            It&#39;s in the spirit of proposing a minimal change. The predicate<br>
            form suffices for all Optional-avoiding search stuff. To reduce<br>
            impact by another 50%, it would suffice to ONLY include the<br>
            &quot;any&quot; form.<br>
                T findAny(Predicate&lt;? super T&gt; predicate, T ifNone);<br>
<br>
            -Doug<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div></div></blockquote>
</blockquote></div><br></div>