<div dir="ltr">Three comments, by the block who opposed the additional mechanism, expressed their view very clearly.  This view is that there should only be one good way to do this, otherwise we have failed.  Doug&#39;s view, when he expressed it before, was that we should add another way in case we are wrong (and to satisfy those who prefer the other way).  If there is a &quot;best of both worlds&quot; argument, I have yet to hear it.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 14, 2013 at 10:06 AM, 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">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>
Here, we did not reach a clear consensus.  However, I think some people may have misunderstood the question.  I&#39;ll let Doug, as proponent of this approach, take another swing at what is being proposed here, and why this might achieve best-of-both-worlds.<div class="HOEnZb">
<div class="h5"><br>
<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>
</div></div></blockquote></div><br></div>