<div dir="ltr"><div style><font face="arial, sans-serif">Doug,</font></div><div style><br></div><div style><font face="arial, sans-serif">I think your point that Optional and non-Optional forms of reduce are already provided is significant.</font></div>
<div style><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I noticed that your proposed versions of findFirst and findAny have a Predicate argument, but the Optional forms do not:</font></div>
<div style><div><span style="font-family:&#39;courier new&#39;,monospace;font-size:13px"><br></span></div><div><span style="font-family:&#39;courier new&#39;,monospace;font-size:13px">T </span><span class="" style="font-family:&#39;courier new&#39;,monospace;font-size:13px">findFirst</span><span style="font-family:&#39;courier new&#39;,monospace;font-size:13px">(Predicate&lt;? super T&gt; predicate, T ifNone);</span><br>
</div><div><span style="font-family:&#39;courier new&#39;,monospace;font-size:13px"><br></span></div><div><div><font face="arial, sans-serif">Why is this?</font></div></div><div><br></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Mar 14, 2013 at 4:36 PM, Doug Lea <span dir="ltr">&lt;<a href="mailto:dl@cs.oswego.edu" target="_blank">dl@cs.oswego.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 03/14/13 13:06, Brian Goetz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;ve closed the survey, results are at:<br>
<br>
<br>
<a href="https://www.surveymonkey.com/sr.aspx?sm=c2NqWp6wXUxCUlr6SY05nYEyYIr7ShzH3IgL4OXPIYM_3d" target="_blank">https://www.surveymonkey.com/<u></u>sr.aspx?sm=<u></u>c2NqWp6wXUxCUlr6SY05nYEyYIr7Sh<u></u>zH3IgL4OXPIYM_3d</a><br>

<br>
<br>
Here, we did not reach a clear consensus.  However, I think some people may have<br>
misunderstood the question.  I&#39;ll let Doug, as proponent of this approach, take<br>
another swing at what is being proposed here, and why this might achieve<br>
best-of-both-worlds.<br>
</blockquote>
<br></div>
The argument is straightforward. Nothing very best-ish about it though:<br>
<br>
1. It is possible to obtain all functionality of all Stream<br>
methods without encountering Optional, except for findAny/findFirst.<br>
<br>
2. Optional remains controversial. Some people hate it. Some<br>
people love it. Why single out findAny/findFirst as a battleground?<br>
<br>
-Doug<br>
<br>
(PS: As always, I think Optional is so great as to be essential if you<br>
have Value types. Oh, we don&#39;t have Value types...)<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 3/10/2013 7:22 PM, Brian Goetz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;ve posted a survey for the EG at:<br>
<br>
   <a href="https://www.surveymonkey.com/s/NSXMYC2" target="_blank">https://www.surveymonkey.com/<u></u>s/NSXMYC2</a><br>
<br>
where people can express their preference between:<br>
  - Leave things as they are (Optional-bearing methods for findXxx and<br>
reduce);<br>
  - Add, as Doug suggests, non-optional versions of these too.<br>
<br>
Implementation / spec complexity is a non-issue here -- the<br>
implementations are trivial.  The sole issue is whether the API is<br>
better with one version or with both.<br>
<br>
The password has been communicated directly to the EG; contact me if you<br>
didn&#39;t get it.<br>
<br>
Usual survey rules: enter your name with your response, all results will<br>
be made public after the survey closes.  I&#39;ll set a closing time of 6PM<br>
PT Wednesday of this week.<br>
<br>
<br>
On 3/6/2013 7:09 AM, Doug Lea wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Restricting to lambda-libs list...)<br>
<br>
On 03/06/13 04:47, Remi Forax wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok, let be nuclear on this,<br>
There is no good reason to introduce Optional&lt;T&gt; in java.util.<br>
</blockquote>
<br>
We agree about most of the rationale for not using Optional.<br>
But there are still people who say they want it.<br>
I don&#39;t think it is productive at this point to<br>
argue about features supporting an Optional-laden<br>
programming style. But we never seem to hit closure<br>
about features supporting an Optional-free style.<br>
So I&#39;d like to re-propose a simple compromise.<br>
In the same way that there are Optional and<br>
basis-returning versions of reduce:<br>
<br>
  T reduce(T identity, BinaryOperator&lt;T&gt; reducer);<br>
  Optional&lt;T&gt; reduce(BinaryOperator&lt;T&gt; reducer);<br>
<br>
(Where the basis-returning one can in turn be used to<br>
avoid Optional-returning min(), etc). We should do the<br>
same at least for find, or  more in keeping with current<br>
API, findFirst and findAny:<br>
<br>
  T findFirst(Predicate&lt;? super T&gt; predicate, T ifNone);<br>
  T findAny(Predicate&lt;? super T&gt; predicate, T ifNone);<br>
<br>
People wanting to avoid Optional can then then<br>
get all of the derived versions (allMatch, plain<br>
findAny, etc) easily enough.<br>
<br>
Surprisingly enough, that&#39;s the only missing<br>
feature that would otherwise enable a completely<br>
Optional-free usage style of the Stream API.<br>
<br>
We have both proposed variants of this several times,<br>
but they don&#39;t seem to go anywhere. It would be nice<br>
to have a calm final discussion about why we would NOT<br>
do such an apparently sensible thing!<br>
<br>
-Doug<br>
<br>
</blockquote></blockquote>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>